diff --git a/content/actions/tutorials/develop-agentic-workflows-in-github-actions.md b/content/actions/tutorials/develop-agentic-workflows-in-github-actions.md new file mode 100644 index 000000000000..8d31eedcf10f --- /dev/null +++ b/content/actions/tutorials/develop-agentic-workflows-in-github-actions.md @@ -0,0 +1,111 @@ +--- +title: Develop agentic workflows in GitHub Actions +shortTitle: Develop agentic workflows +intro: 'Use {% data variables.copilot.github_agentic_workflows %} to turn Markdown instructions into automations powered by third-party coding agents.' +versions: + feature: copilot +contentType: tutorials +category: + - Write workflows +--- + +{% data reusables.copilot.agentic-workflows-preview-note %} + +## Introduction + +{% data variables.copilot.github_agentic_workflows %} let you define repository automations in Markdown and choose the AI coding agent that runs them. The `gh aw` extension compiles each agentic workflow into a {% data variables.product.prodname_actions %} workflow. + +The entire workflow lifecycle—authoring, debugging, and optimization—is itself agentic. You describe what you want in natural language and a coding agent creates, refines, and troubleshoots the workflow for you. + +This tutorial uses a coding agent to create an automated pull request reviewer that checks whether changes are adequately tested. + +## Prerequisites + +Before you begin, make sure you have: + +* A repository where {% data variables.product.prodname_actions %} is enabled and you have write access +* {% data variables.product.prodname_cli %} version 2.0.0 or later installed and authenticated +* Access to a supported coding agent, such as {% data reusables.copilot.agentic-workflows-third-party-agent-clis %}, or {% data variables.copilot.copilot_cli_short %}, and its required credential + +To authenticate {% data variables.product.prodname_cli %}, run: + +```shell +gh auth login --scopes repo,workflow +``` + +## Installing the `gh aw` extension + +Install the {% data variables.copilot.github_agentic_workflows %} extension for {% data variables.product.prodname_cli %}: + +```shell +gh extension install github/gh-aw +``` + +## Choosing an agent and configuring authentication + +Choose the agent CLI that best fits your workflow. {% data reusables.copilot.agentic-workflows-third-party-agent-clis %}, and {% data variables.copilot.copilot_cli_short %} can all run {% data variables.copilot.github_agentic_workflows %}. + +This article walks through a simple setup that adds the agent's credential as a repository secret. If you use {% data reusables.copilot.agentic-workflows-third-party-agent-clis %}, store the agent's API key as a repository secret. + +| Agent CLI | `engine` value | Repository secret | +| --- | --- | --- | +| Claude Code | `claude` | `ANTHROPIC_API_KEY` containing an Anthropic API key | +| {% data variables.product.prodname_openai_codex %} | `codex` | `OPENAI_API_KEY` containing an OpenAI API key | +| Google {% data variables.copilot.copilot_gemini %} CLI | `gemini` | `GEMINI_API_KEY` containing a Google AI Studio API key | +| {% data variables.copilot.copilot_cli_short %} (default) | `copilot` | No secret needed for organization repositories (see below). For personal repositories, `COPILOT_GITHUB_TOKEN` containing a fine-grained {% data variables.product.pat_generic %} with **Copilot Requests** set to **Read**. | + +Other engines such as Pi (experimental) are also supported. For the full list, see the [{% data variables.copilot.github_agentic_workflows %} authentication reference](https://github.github.com/gh-aw/reference/auth/). + +### Organization billing for {% data variables.product.prodname_copilot %} + +If you use {% data variables.product.prodname_copilot %} in an organization-owned repository, you can use {% data variables.product.prodname_actions %}' built-in `GITHUB_TOKEN` instead of a {% data variables.product.pat_generic %}. Add `copilot-requests: write` to your workflow frontmatter `permissions` and no separate secret is required. For setup steps, see [AUTOTITLE](/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows#using-the-built-in-github_token). + +### Storing a secret in the GitHub UI + +To add a secret for {% data reusables.copilot.agentic-workflows-third-party-agent-clis %}, or {% data variables.product.prodname_copilot %} personal repositories: + +1. On {% data variables.product.github %}, navigate to your repository. +1. Under your repository name, click **{% octicon "gear" aria-hidden="true" aria-label="gear" %} Settings**. +1. In the sidebar, click **Secrets and variables**, then click **Actions**. +1. Click **New repository secret**. +1. In the **Name** field, enter the secret name from the table above. +1. In the **Secret** field, enter the value. +1. Click **Add secret**. + +## Creating the workflow + +Use a coding agent to create the workflow from a natural language description. + +1. From your repository root, initialize the repository for agentic authoring. This adds skills and instructions that help the coding agent create and edit workflows: + + ```shell + gh aw init + ``` + +1. Start a coding agent session in the context of your repository—for example, using {% data reusables.copilot.agentic-workflows-third-party-agent-clis %}, {% data variables.copilot.copilot_cli_short %}, or VS Code agent mode. +1. Use the `agentic-workflows` skill and describe the workflow you want: + + ```copilot copy + /agentic-workflows create a pr reviewer that ensure the changes are tested. + ``` + + The agent creates a workflow Markdown file in `.github/workflows/`, compiles the corresponding `.lock.yml` {% data variables.product.prodname_actions %} workflow file, and asks you to review and commit both files. + +1. Review the generated workflow, then ask the agent to commit and push the files. + +> [!TIP] +> You can use the same agentic approach to update and improve the workflow after it runs. Ask the agent to refine the review criteria, add more checks, or debug a failed run—all in natural language. If you edit the workflow frontmatter later, run `gh aw compile` before committing your changes. + +## Running the workflow + +The generated workflow triggers automatically on pull requests, so it runs the next time you open or update a pull request in your repository. + +1. Open a pull request in your repository. +1. On {% data variables.product.github %}, navigate to your repository and click the **Actions** tab. +1. In the left sidebar, select the workflow that the agent created. +1. Once the run completes, the workflow leaves a pull request review noting whether the changes include enough tests. + +## Next steps + +* To create a workflow that produces a weekly issue activity report, see [AUTOTITLE](/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows). +* For advanced engine configuration, safe outputs, and more workflow examples, see the [{% data variables.copilot.github_agentic_workflows %} documentation site](https://github.github.com/gh-aw/). diff --git a/content/actions/tutorials/index.md b/content/actions/tutorials/index.md index fbeb01db9775..a0158e1e27f2 100644 --- a/content/actions/tutorials/index.md +++ b/content/actions/tutorials/index.md @@ -18,6 +18,7 @@ children: - /use-containerized-services - /migrate-to-github-actions - /use-actions-runner-controller + - /develop-agentic-workflows-in-github-actions redirect_from: - /actions/guides - /actions/how-tos/use-cases-and-examples @@ -27,4 +28,3 @@ redirect_from: - /actions/use-cases-and-examples contentType: tutorials --- - diff --git a/content/admin/data-residency/network-details-for-ghecom.md b/content/admin/data-residency/network-details-for-ghecom.md index 9ab6e88c3692..529b7f71aca7 100644 --- a/content/admin/data-residency/network-details-for-ghecom.md +++ b/content/admin/data-residency/network-details-for-ghecom.md @@ -42,9 +42,24 @@ git clone SUBDOMAIN@SUBDOMAIN.ghe.com:OWNER/REPO.git * `*.actions.{% data variables.enterprise.data_residency_domain %}` * `*.githubassets.com` * `*.githubusercontent.com` -* `*.blob.core.windows.net` +* `*.blob.core.windows.net`. If you cannot allow access to wildcard domains, see [Azure Blob Storage hostnames](#azure-blob-storage-hostnames). * `auth.ghe.com` +### Azure Blob Storage hostnames + +If you cannot allow access to `*.blob.core.windows.net`, use the `/meta` API endpoint for your enterprise to retrieve the complete list of client-facing Azure Blob Storage hostnames. For example, using the {% data variables.product.prodname_cli %}: + +```shell +gh api /meta --hostname octocorp.ghe.com --jq '.domains.storage[]' +``` + +Allow access to every hostname returned in `domains.storage`. The list is specific to your enterprise and {% data variables.product.company_short %} keeps it up to date as network requirements change. + +For more information about the `/meta` endpoint, see [AUTOTITLE](/rest/meta/meta#get-github-meta-information). + +> [!NOTE] +> If you stream audit logs to your own Azure Blob Storage destination, you must allow access to that destination separately. + ## {% data variables.product.github %}'s IP addresses {% data variables.product.company_short %}'s IP address ranges for enterprises on {% data variables.enterprise.data_residency_site %} depend on your chosen region. @@ -204,41 +219,9 @@ Japan region: * `.ghe.com` * `github.com` * `*.githubusercontent.com` -* `*.blob.core.windows.net` (can be further restricted by region, see below) +* `*.blob.core.windows.net`. To allow access only to the hostnames used by your enterprise, see [Azure Blob Storage hostnames](#azure-blob-storage-hostnames). * `*.web.core.windows.net` -#### EU - -`*.blob.core.windows.net` can be replaced with: -* `memoryalphaprodsdc01.blob.core.windows.net` -* `memoryalphaprodweu01.blob.core.windows.net` -* `prodsdc01resultssa0.blob.core.windows.net` -* `prodsdc01resultssa1.blob.core.windows.net` -* `prodsdc01resultssa2.blob.core.windows.net` -* `prodsdc01resultssa3.blob.core.windows.net` -* `prodweu01resultssa0.blob.core.windows.net` -* `prodweu01resultssa1.blob.core.windows.net` -* `prodweu01resultssa2.blob.core.windows.net` -* `prodweu01resultssa3.blob.core.windows.net` - -#### Australia - -`*.blob.core.windows.net` can be replaced with: -* `memoryalphaprodae01.blob.core.windows.net` -* `prodae01resultssa0.blob.core.windows.net` -* `prodae01resultssa1.blob.core.windows.net` -* `prodae01resultssa2.blob.core.windows.net` -* `prodae01resultssa3.blob.core.windows.net` - -#### Japan - -`*.blob.core.windows.net` can be replaced with: -* `memoryalphaprodjpw01.blob.core.windows.net` -* `prodjpw01resultssa0.blob.core.windows.net` -* `prodjpw01resultssa1.blob.core.windows.net` -* `prodjpw01resultssa2.blob.core.windows.net` -* `prodjpw01resultssa3.blob.core.windows.net` - ### OAuth callback URL for connecting an Azure subscription for billing When you connect or update an Azure subscription for billing, you must allow access to the following URL: diff --git a/content/communities/moderating-comments-and-conversations/limiting-interactions-in-your-organization.md b/content/communities/moderating-comments-and-conversations/limiting-interactions-in-your-organization.md index e755f51f69a3..2457b507c549 100644 --- a/content/communities/moderating-comments-and-conversations/limiting-interactions-in-your-organization.md +++ b/content/communities/moderating-comments-and-conversations/limiting-interactions-in-your-organization.md @@ -38,6 +38,24 @@ Organization owners and moderators can also block users for a specific amount of {% data reusables.community.set-interaction-limit %} +{% ifversion pull-request-limit %} + +## Limiting concurrent open pull requests for users without write access + +Across all public repositories owned by your organization, you can set a maximum number of pull requests that a user without write access can have open at the same time. This limit applies separately to each repository, so a user without write access can have up to the configured maximum number of open pull requests in _each_ public repository owned by the organization, not across the organization as a whole. When a user without write access reaches the limit in a repository, they must close an existing pull request or wait for someone with write access to merge one before they can open a new one. + +This setting helps maintainers manage contribution volume by preventing users from opening an excessive number of pull requests, which can overwhelm review queues and trigger unnecessary CI runs. The limit only applies to users without write access—users with write access or higher are not affected. + +Draft pull requests do not count toward a user's limit. Only open, non-draft pull requests are counted when determining whether a user has reached the maximum. + +The organization-level limit takes precedence, but if a repository owned by your organization has its own pull request limit configured after the organization-level limit, the repository-level limit overrides the organization-level limit. See [AUTOTITLE](/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository#limiting-concurrent-open-pull-requests-for-users-without-write-access). + +### Configuring the pull request limit + +To configure the pull request limit, navigate to the **Interaction limits** settings page following the same steps described in [Limiting interactions in your organization](#limiting-interactions-in-your-organization), then under **Pull request limits**, select the maximum number of concurrent open pull requests allowed for users without write access. You can also use the REST API to configure the pull request limit. See [AUTOTITLE](/rest/interactions/orgs#update-pull-request-creation-cap-for-an-org). + +{% endif %} + ## Further reading * [AUTOTITLE](/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam) diff --git a/content/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository.md b/content/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository.md index fcbdb02fd0e8..3fabc4a83c04 100644 --- a/content/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository.md +++ b/content/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository.md @@ -31,6 +31,8 @@ You can also enable activity limitations on all repositories owned by your perso 1. In the sidebar, select **{% octicon "comment-discussion" aria-hidden="true" aria-label="comment-discussion" %} Moderation options**, then click **Interaction limits**. {% data reusables.community.set-interaction-limit %} +{% ifversion pull-request-limit %} + ## Limiting concurrent open pull requests for users without write access In a public repository, you can set a maximum number of pull requests that a user without write access can have open at the same time. When a user without write access reaches the limit, they can close or merge an existing pull request before they can open a new one. @@ -52,6 +54,8 @@ To configure the pull request limit, navigate to the **Interaction limits** sett 1. Under **Pull request limits**, select the maximum number of concurrent open pull requests allowed for users without write access. 1. Optionally, under **Bypass list**, search for and select the users you want to allow to bypass the pull request limit. +{% endif %} + ## Further reading * [AUTOTITLE](/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam) diff --git a/content/copilot/concepts/agents/copilot-cli/cancel-and-roll-back.md b/content/copilot/concepts/agents/copilot-cli/cancel-and-roll-back.md index 3177021d02f8..9fdabfeb4498 100644 --- a/content/copilot/concepts/agents/copilot-cli/cancel-and-roll-back.md +++ b/content/copilot/concepts/agents/copilot-cli/cancel-and-roll-back.md @@ -1,7 +1,7 @@ --- title: Canceling a {% data variables.copilot.copilot_cli %} operation and rolling back changes shortTitle: Cancel and roll back -intro: 'Find out about the different ways to cancel an active {% data variables.product.prodname_copilot_short %} operation, and how to roll back changes made during a session if the result isn''t what you expected.' +intro: "Find out about the different ways to cancel an active {% data variables.product.prodname_copilot_short %} operation, and how to roll back changes made during a session if the result isn't what you expected." versions: feature: copilot contentType: concepts @@ -19,20 +19,30 @@ When you work in an interactive {% data variables.copilot.copilot_cli_short %} s * Ctrl+C acts immediately, without a confirming second press—removing any queued prompts first (one per press), then canceling the current operation. * A single Esc keypress gives you more gradual, staged control. While {% data variables.product.prodname_copilot_short %} is actively working, a single Esc doesn't cancel right away—it shows a reminder, and a second press carries out the next step: removing the most recently queued prompt, or canceling the operation once nothing is queued. -If {% data variables.product.prodname_copilot_short %} has already made changes and you want to undo them, you can roll back your workspace to a previous point in the session. {% data variables.copilot.copilot_cli_short %} takes a snapshot of your workspace state each time you enter a prompt, and this allows you to rewind to an earlier state by pressing Esc twice when {% data variables.product.prodname_copilot_short %} is idle and the input area is empty. +If {% data variables.product.prodname_copilot_short %} has already made changes and you want to undo them, you can roll back to a previous point in the session. As {% data variables.product.prodname_copilot_short %} works, {% data variables.copilot.copilot_cli_short %} tracks the file changes it makes as it responds to each prompt. This lets you rewind to an earlier point by pressing Esc twice when {% data variables.product.prodname_copilot_short %} is idle and the input area is empty. When you rewind, you choose whether to rewind the conversation only, or to also restore the files that {% data variables.product.prodname_copilot_short %} changed. ## What pressing Esc does in different situations Pressing Esc once performs different actions depending on the current state of the session: | Current state | What pressing Esc does | -| ------------- | ------------------------ | +| ------------- | --------------------------------- | | {% data variables.product.prodname_copilot_short %} is active with no queued prompts. | Shows an "Esc again to cancel" reminder. The running operation is canceled only if you press Esc again within half a second. | | {% data variables.product.prodname_copilot_short %} is active and there are queued prompts. | Shows the "Esc again to cancel" reminder. Pressing Esc again removes the most recently queued prompt. | | A permission dialog is open. | A single Esc denies the pending request (no second press needed). | | A dialog, overlay, or picker is open. | Closes the dialog, overlay, or picker. | | {% data variables.product.prodname_copilot_short %} is idle. | Shows a brief reminder that pressing Esc again quickly will open the rewind picker. See [Rolling back changes](#rolling-back-changes). | +Pressing Esc twice quickly, when {% data variables.product.prodname_copilot_short %} is idle, allows you to roll back to an earlier point in the session. If an operation is in progress, a double Esc does one of the following, in this order of priority: + +* Cancels a running shell command. +* Stops the current response. +* Stops background agents. +* Clears text in the input area. +* Exits shell mode. + +If none of these applies, the rewind picker is displayed. + ## When to use Esc instead of Ctrl+C The main difference between these two ways of canceling an operation is that Esc is designed for gradual, targeted intervention, while Ctrl+C is a hard stop. @@ -45,7 +55,14 @@ As a rule of thumb, use Esc when you want to intervene selectively, a ## Rolling back changes -While {% data variables.product.prodname_copilot_short %} is inactive and there is no text in the input area, you can press Esc twice to display a list of points in your current session that you can roll back to. Each point corresponds to a snapshot of your workspace that was taken immediately before {% data variables.product.prodname_copilot_short %} started working on the prompt shown in the list. +While {% data variables.product.prodname_copilot_short %} is inactive and there is no text in the input area, you can press Esc twice to display a list of points in your current session that you can roll back to. Each point corresponds to a prompt you submitted, and rewinding takes the session back to the state it was in immediately before {% data variables.product.prodname_copilot_short %} started working on that prompt. + +After you choose a rewind point, you decide whether to: + +* **Rewind the conversation only**, leaving your files untouched. +* **Rewind the conversation and restore files**, which reverts the files {% data variables.product.prodname_copilot_short %} changed while leaving your own later edits in place. + +Because it restores only the files {% data variables.product.prodname_copilot_short %} changed rather than your whole workspace, rewind works in any directory, including folders that aren't Git repositories. For full details of how to use the double Esc keypress to roll back changes made during a session, see [AUTOTITLE](/copilot/how-tos/copilot-cli/use-copilot-cli/roll-back-changes). @@ -54,23 +71,28 @@ For full details of how to use the double Esc keypress to roll back c ### What happens when you roll back -When you select a snapshot from the rewind picker, the following actions occur: +The actions that occur when you roll back depend on the option you choose. + +If you choose to rewind the conversation **and** restore files: + +1. **Files are restored.** The files {% data variables.product.prodname_copilot_short %} changed are reverted to the state they were in before the selected prompt. Files whose current contents no longer match what {% data variables.product.prodname_copilot_short %} last wrote—for example, because you edited them yourself—are skipped so your later edits aren't overwritten. +1. **Session history is truncated.** The conversation is rewound to the selected point. All messages and tool calls that occurred after that point are removed from the session. +1. **Obsolete snapshots are removed.** The captured file changes for the discarded turns are cleaned up. Earlier points remain available for future rewinds. +1. **Rollback confirmed.** After the rollback, {% data variables.product.prodname_copilot_short %} displays a message indicating how many files were restored, and notes any files that were skipped. +1. **Your prompt is restored.** The prompt associated with the selected point is placed in the input area, so you can edit and resubmit it. -1. **Git state is restored.** The repository is checked out to the Git commit and branch recorded in the snapshot. -1. **Untracked files are cleaned.** Files that did not exist at the time of the snapshot are removed. -1. **Modified files are restored.** Files that were changed after the snapshot are reverted to their backed-up state, including permissions and staging state. -1. **Session history is truncated.** The conversation is rewound to the point where the selected snapshot was taken. All messages and tool calls that occurred after that point are removed from the session. -1. **Snapshots are removed.** The selected snapshot and all snapshots after it are permanently deleted. Only snapshots from earlier conversation steps remain available for future rewinds. -1. **Rollback confirmed.** After the rollback, {% data variables.product.prodname_copilot_short %} displays a message indicating how many files were restored. -1. **Your prompt is restored.** The prompt associated with the selected snapshot is placed in the input area. +If you choose to rewind the conversation only, your files are left untouched: the session history is truncated (step 2) and your prompt is restored to the input area (step 5). ### Changes that can't be rolled back -Rewind is unavailable in the following situations: +File restoration is skipped, or unavailable, in the following situations: -* **Files over 10 MB.** Individual files larger than 10 MB are skipped during snapshot creation. Changes to these files are not restored during a rollback. -* **More than 500 changed files.** If more than 500 files were changed during a single step of a CLI conversation, a snapshot is not created for that step. You will not be able to roll back changes made in that step. Earlier snapshots are unaffected. +* **Files over 10 MB.** Individual files larger than 10 MB are skipped during capture, so changes to those files are not restored during a rollback. +* **More than 500 changed files.** If more than 500 files were changed during a single turn, file changes for that turn are not captured, so you won't be able to restore files for it. Other turns are unaffected. +* **Files you changed yourself.** Files whose current contents no longer match what {% data variables.product.prodname_copilot_short %} last wrote are left untouched rather than overwritten. +* **Sessions without file tracking.** If you resume a session that started before file-change tracking was enabled, only conversation rewind is available. Start a new session to be able to restore file changes. +* **Remote-backed or busy sessions.** Rewind isn't available for remote-backed sessions, or while the session still has work in progress. ## Further reading -* [AUTOTITLE](/copilot/reference/copilot-cli-reference/cli-command-reference) +- [AUTOTITLE](/copilot/reference/copilot-cli-reference/cli-command-reference) diff --git a/content/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/configure-enterprise-managed-settings.md b/content/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/configure-enterprise-managed-settings.md index c65f0984c472..a7343bb1d3ce 100644 --- a/content/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/configure-enterprise-managed-settings.md +++ b/content/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/configure-enterprise-managed-settings.md @@ -21,6 +21,7 @@ The following clients are supported, although not every client supports every pr * {% data variables.copilot.copilot_cli_short %} * {% data variables.product.prodname_vscode_shortname %} +* {% data variables.product.prodname_jetbrains_ides %} * The {% data variables.copilot.github_copilot_app %} * {% data variables.copilot.copilot_cloud_agent %} @@ -85,7 +86,7 @@ For example, to defer both `model` and `disableBypassPermissionsMode`: } ``` -1. Create the team settings file under `copilot/{% data variables.copilot.team_settings_directory %}`. Include only the keys you marked as overridable. Every other key stays governed by your enterprise default. +1. Create the team settings file under `copilot/{% data variables.copilot.team_settings_directory %}`. You can include any keys you marked as overridable, plus the additive keys `enabledPlugins` and `extraKnownMarketplaces`. Every other key stays governed by your enterprise default. ```json { @@ -170,7 +171,7 @@ Server-managed settings require an organization and a `.github-private` reposito 1. Add settings to the repository in a `copilot/{% data variables.copilot.managed_setting_file %}` file. 1. Set that organization as the source of governance for your enterprise's AI standards. See [AUTOTITLE](/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/create-github-private-repo#selecting-your-repository-as-your-source-of-governance). -From that point on, any user on your enterprise's {% data variables.product.prodname_copilot_short %} plan using {% data variables.copilot.copilot_cli_short %} or {% data variables.product.prodname_vscode_shortname %} is governed by those settings, whether or not they have access to the `.github-private` repository. +From that point on, any user on your enterprise's {% data variables.product.prodname_copilot_short %} plan using {% data variables.copilot.copilot_cli_short %} or supported clients is governed by those settings, whether or not they have access to the `.github-private` repository. The main limitation of this method is the {% data variables.product.prodname_enterprise %} license requirement to create the organization and repository. diff --git a/content/copilot/how-tos/copilot-cli/use-copilot-cli/roll-back-changes.md b/content/copilot/how-tos/copilot-cli/use-copilot-cli/roll-back-changes.md index 6c959f9a548f..f4c9b5023206 100644 --- a/content/copilot/how-tos/copilot-cli/use-copilot-cli/roll-back-changes.md +++ b/content/copilot/how-tos/copilot-cli/use-copilot-cli/roll-back-changes.md @@ -1,7 +1,7 @@ --- title: Rolling back changes made during a {% data variables.copilot.copilot_cli %} session shortTitle: Roll back changes -intro: 'Rewind your {% data variables.copilot.copilot_cli_short %} session to a previous prompt to undo changes in conversation history, and optionally restore files.' +intro: "Rewind your {% data variables.copilot.copilot_cli_short %} session to a previous prompt to undo changes in conversation history, and optionally restore files." versions: feature: copilot contentType: how-tos @@ -18,55 +18,44 @@ docsTeamMetrics: When you work in an interactive {% data variables.copilot.copilot_cli_short %} session, {% data variables.product.prodname_copilot_short %} can make changes to files, run shell commands, and modify your repository. If the result isn't what you expected, you can rewind to a previous point in the session to undo those changes. -You can trigger a rewind by pressing Esc twice, or by using the `/undo` slash command (or its alias `/rewind`). +You can trigger a rewind by pressing Esc twice when {% data variables.product.prodname_copilot_short %} is idle, or by using the `/undo` slash command (or its alias `/rewind`). -{% data variables.copilot.copilot_cli_short %} supports two rewind behaviors: +When you select a point to rewind to, you can choose whether to **Rewind the conversation only** or **Rewind the conversation and restore files**. -* **Git-based rewind**: rolls back to a workspace snapshot taken at the start of a prompt. -* **Tools-based rewind**: lets you rewind conversation history only, or rewind conversation history and restore files that {% data variables.product.prodname_copilot_short %} changed. - -> [!NOTE] -> Tools-based rewind is currently an experimental feature and is only available if you have used the `/experimental on` slash command, or the `‑‑experimental` command line option. - -{% data variables.copilot.copilot_cli_short %} automatically chooses one of these rewind behaviors based on your environment to provide the best possible rewind experience. - -To tell which of the rewind behaviors is active: - -* If the picker immediately shows snapshots and selecting one performs the rollback, you're using **Git-based rewind**. -* If selecting a rewind point opens an action menu with **Conversation only** and **Conversation + files**, you're using **tools-based rewind**. +Rewind works in any directory, including folders that aren't Git repositories. It restores only the files that {% data variables.product.prodname_copilot_short %} changed. This article explains how to roll back changes. For more conceptual information about rewinding to an earlier point in a session, see [AUTOTITLE](/copilot/concepts/agents/copilot-cli/cancel-and-roll-back). ## Prerequisites * **A rewind point must exist.** You can't roll back before your first prompt in a session. -* **For Git-based rewind only:** you must be in a Git repository with at least one commit. -* **For tools-based rewind:** file restoration can be skipped for files that were changed after {% data variables.product.prodname_copilot_short %} last touched them. +* **File restoration is only available for sessions that tracked file changes.** If you resume a session that started before file-change tracking was enabled, only conversation rewind is offered. Start a new session to be able to restore file changes. +* **File restoration skips files you changed yourself.** Files whose current contents no longer match what {% data variables.product.prodname_copilot_short %} last wrote (for example, because you edited them afterward), and files that were too large to back up, are left untouched rather than overwritten. +* **Rewind isn't available for remote-backed sessions**, or while the session still has work in progress. ## Rolling back with a double Esc keypress > [!WARNING] +> > * Rewinding cannot be undone. Once you roll back, later session history is permanently removed. -> * In **Git-based rewind**, rolling back restores your entire workspace to the state it was in at the selected snapshot. This reverts all changes made after that point—not only changes made by {% data variables.product.prodname_copilot_short %}, but also any manual edits and changes from shell commands. Any new files created in the workspace after the snapshot was taken are deleted, regardless of their Git status. -> * In **tools-based rewind**, you can choose whether to restore files. If you choose file restoration, files changed after {% data variables.product.prodname_copilot_short %} may be left unchanged to avoid overwriting your newer edits. +> * If you choose to restore files, {% data variables.product.prodname_copilot_short %} restores only the files it changed, and skips any file whose current contents no longer match what it last wrote, so your own later edits aren't overwritten. + +Pressing Esc twice only opens the rewind picker when {% data variables.product.prodname_copilot_short %} is idle. For details of what a double Esc does when an operation is in progress, see [AUTOTITLE](/copilot/concepts/agents/copilot-cli/cancel-and-roll-back#what-pressing-esc-does-in-different-situations). When {% data variables.product.prodname_copilot_short %} has finished responding to a prompt you've entered: -1. Make sure the input area is empty. If there's text in the input area, pressing Esc twice in quick succession clears the text. +1. Make sure the input area is empty and no work is in progress. If there's text in the input area, pressing Esc twice in quick succession clears the text instead of opening the picker. 1. Press Esc twice in quick succession to open the rewind picker. - The picker lists available rewind points for the current session, with the most recent first. The ten most recent points are displayed at once. If there are more than ten, use the ↓ arrow key to scroll down through earlier points. - For each rewind point, the beginning of the prompt you entered is shown, with an indication of how long ago you submitted it. + The picker lists available rewind points for the current session, with the most recent first. The ten most recent points are displayed at once. If there are more than ten, use the ↑ and ↓ arrow keys to scroll through them. + For each rewind point, the beginning of the prompt you entered is shown, along with how long ago you submitted it. For turns that changed files, the number of lines added and removed by that turn is also shown. -1. Choose a rewind point. +1. Choose a rewind point and press Enter. - * In Git-based rewind, selecting a snapshot restores the workspace to the state at the start of that prompt. - * In tools-based rewind, after choosing a rewind point you can select: - * **Conversation only** (history rewound, files unchanged), or - * **Conversation + files** (history rewound and restorable files changed by {% data variables.product.prodname_copilot_short %} are restored). + Choosing a rewind point opens an action menu where you can select **Conversation only** or **Conversation + files**. The latter is unavailable for a rewind point when neither that turn nor any later turn changed any files that can be restored. Before restoring, {% data variables.product.prodname_copilot_short %} shows a per-file preview of the changes so you can confirm. > [!NOTE] - > In Git-based rewind, the repository is rolled back to its state immediately before {% data variables.product.prodname_copilot_short %} started working on the prompt, not immediately after it finished working on the prompt. + > The rewind is applied relative to the state immediately **before** {% data variables.product.prodname_copilot_short %} started working on the prompt, not immediately after it finished working on the prompt. The prompt you selected is shown in the input area, so you can edit and resubmit it, if required. @@ -82,12 +71,12 @@ After rolling back, you can use Git commands to verify the state of your reposit Typing `!` allows you to run shell commands directly from the {% data variables.copilot.copilot_cli_short %} input prompt, so you don't need to exit the CLI to check the repository state. -| To do this | Enter this command | -| ---------- | ------------------------ | -| Check which files show as modified, staged, or untracked. | `! git status` | +| To do this | Enter this command | +| --------------------------------------------------------- | ------------------------ | +| Check which files show as modified, staged, or untracked. | `! git status` | | Show the SHA and commit message of the current commit. | `! git log --oneline -1` | -| Review the unstaged changes. | `! git diff` | +| Review the unstaged changes. | `! git diff` | ## Further reading -* [AUTOTITLE](/copilot/reference/copilot-cli-reference/cli-command-reference) +- [AUTOTITLE](/copilot/reference/copilot-cli-reference/cli-command-reference) diff --git a/content/copilot/reference/copilot-cli-reference/cli-command-reference.md b/content/copilot/reference/copilot-cli-reference/cli-command-reference.md index afc85afe3403..0172250ca7b5 100644 --- a/content/copilot/reference/copilot-cli-reference/cli-command-reference.md +++ b/content/copilot/reference/copilot-cli-reference/cli-command-reference.md @@ -362,7 +362,7 @@ These are the slash commands you can use from within an interactive CLI session. | `/terminal-setup` | Configure the terminal for multiline input support (Shift+Enter and Ctrl+Enter). | | `/theme [default\|github\|dim\|high-contrast\|colorblind]` | View or set the color mode. | | `/tuikit [colors\|icons\|select\|tabbar]` | Preview TUIkit design-system components and color tokens. | -| `/undo`, `/rewind` | Rewind a turn. Offers two restoration modes: conversation-only (roll back the conversation) or conversation + files (also revert file changes from that turn). File changes are tracked per turn across editing tools, shell commands, and sub-agents, so Git is not required. | +| `/undo`, `/rewind` | Open the rewind picker to roll the session back to an earlier user turn. Choose between: **Conversation only** (roll back the conversation, leaving files as they are) or **Conversation + files** (also restore the files {% data variables.product.prodname_copilot_short %} changed in that turn, and later discarded turns, to their pre-change contents, skipping any you have since edited yourself). File changes are tracked per turn across editing tools, shell commands, and sub-agents, so Git is not required. | | `/update`, `/upgrade` | Update the CLI to the latest version. | | `/usage` | Display session usage metrics and statistics, including per-model token totals. | | `/user [show\|list\|switch]` | Manage the current {% data variables.product.github %} user. | diff --git a/content/enterprise-onboarding/getting-started-with-your-enterprise/about-migrating-to-github-enterprise-cloud.md b/content/enterprise-onboarding/getting-started-with-your-enterprise/about-migrating-to-github-enterprise-cloud.md deleted file mode 100644 index b87edc6e7807..000000000000 --- a/content/enterprise-onboarding/getting-started-with-your-enterprise/about-migrating-to-github-enterprise-cloud.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: About migrating to GitHub Enterprise Cloud -intro: Explore migrating your current solution into {% data variables.product.prodname_ghe_cloud %}. -versions: - ghec: '*' -shortTitle: Migrations -contentType: concepts -docsTeamMetrics: - - enterprise-onboarding ---- - -{% data reusables.migrations.about-migrations %} - -{% data variables.product.company_short %} provides a variety of different tools to support these migrations. Different tools support different migration pathways and provide different levels of migration fidelity. To determine the best tool for your migration, understand what you can migrate, and learn how to make your migration successful, see [AUTOTITLE](/migrations/overview/planning-your-migration-to-github). - -The steps you will take to migrate to {% data variables.product.prodname_ghe_cloud %} include: - -1. Define the origin (source) for your migration. Your destination is {% data variables.product.prodname_ghe_cloud %}. -1. Understand what data you will migrate, and build a basic inventory. -1. Evaluate the size of your migration data, and recognize if you need to first move any repositories to Git. -1. Decide on your migration type, based on your organization's needs and the tools available to you. -1. Choose if you will perform the migration yourself (a "self-serve migration"), or if you will work with {% data variables.product.company_short %}'s Expert Services team or a {% data variables.product.company_short %} Partner (an "expert-led migration"). - -In a later stage of setting up your trial, when you're ready to create your organization and teams, you will take additional steps to finish your migration, including: - -1. Design your organization structure for the migration to {% data variables.product.prodname_ghe_cloud %}. -1. Plan a test of your migration, including performing a dry run migration of all your repositories. -1. Establish your pre-migration and post-migration steps, and create a migration plan. -1. Prepare your organization and schedule for the migration. -1. Perform the migration, and execute any post-migration tasks. - -## About enterprise migrations to {% data variables.product.prodname_actions %} - -To migrate your enterprise to {% data variables.product.prodname_actions %} from an existing system, you can plan the migration, complete the migration, and retire existing systems. - -If you're planning to switch to {% data variables.product.prodname_actions %}, we do not recommend doing so at the same time that you migrate your repositories. Instead, wait until a later date, and perform your CI/CD migration as a separate step. This makes the migration process more manageable. - -## Next steps - -Now that you've started your trial and added users to your enterprise, you can set up organizations and teams to manage access. See [AUTOTITLE](/enterprise-onboarding/setting-up-organizations-and-teams/best-practices). diff --git a/content/enterprise-onboarding/getting-started-with-your-enterprise/index.md b/content/enterprise-onboarding/getting-started-with-your-enterprise/index.md index 79837c1a6012..0c58ad7d52ca 100644 --- a/content/enterprise-onboarding/getting-started-with-your-enterprise/index.md +++ b/content/enterprise-onboarding/getting-started-with-your-enterprise/index.md @@ -6,7 +6,6 @@ versions: shortTitle: Get started children: - /setting-up-a-trial-of-github-enterprise - - /about-migrating-to-github-enterprise-cloud docsTeamMetrics: - enterprise-onboarding --- diff --git a/content/enterprise-onboarding/index.md b/content/enterprise-onboarding/index.md index bbd361bbad1b..205fc59017fd 100644 --- a/content/enterprise-onboarding/index.md +++ b/content/enterprise-onboarding/index.md @@ -11,7 +11,7 @@ journeyTracks: - href: '/enterprise-onboarding/getting-started-with-your-enterprise/setting-up-a-trial-of-github-enterprise' - href: '/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/add-users' - href: '/billing/concepts/enterprise-billing/billing-for-enterprises' - - href: '/enterprise-onboarding/getting-started-with-your-enterprise/about-migrating-to-github-enterprise-cloud' + - href: '/migrations/overview/planning-your-migration-to-github' - id: 'setting_up_organizations_and_teams' title: 'Setting up organizations and teams in your enterprise' description: 'Organize work effectively and ensure people have the access they need to resources and administrative settings.' diff --git a/content/migrations/overview/planning-your-migration-to-github.md b/content/migrations/overview/planning-your-migration-to-github.md index 14cb66289bb8..5ef5060e545f 100644 --- a/content/migrations/overview/planning-your-migration-to-github.md +++ b/content/migrations/overview/planning-your-migration-to-github.md @@ -1,13 +1,17 @@ --- title: Planning your migration to GitHub shortTitle: Plan your migration -intro: 'Learn how to plan and execute a successful migration to {% data variables.product.company_short %} or between {% data variables.product.company_short %} products.' +intro: 'Plan and execute a successful migration to {% data variables.product.company_short %} or between {% data variables.product.company_short %} products.' versions: fpt: '*' ghes: '*' ghec: '*' category: - Plan your migration +redirect_from: + - /enterprise-onboarding/getting-started-with-your-enterprise/about-migrating-to-github-enterprise-cloud +docsTeamMetrics: + - enterprise-onboarding --- ## About migrations @@ -67,7 +71,13 @@ If you’re migrating from Azure DevOps, we recommend the `inventory-report` com If you’re migrating from Bitbucket Server or Bitbucket Data Center, we recommend the `inventory-report` command in the {% data variables.product.prodname_bbs2gh_cli %}. The `inventory-report` command will use your Bitbucket instance's API to build a simple CSV. For more information about how to install the {% data variables.product.prodname_bbs2gh_cli %}, see [AUTOTITLE](/migrations/using-github-enterprise-importer/migrating-from-bitbucket-server-to-github-enterprise-cloud/migrating-repositories-from-bitbucket-server-to-github-enterprise-cloud). -For other migration origins, create your migration inventory yourself. You could build the spreadsheet using the origin’s reporting tools, if available, or API, or you could create the inventory manually. +Depending on your migration path, there are various tools you can use to collect this data: + +* If your source is another {% data variables.product.github %} product, the third-party `gh-repo-stats` extension for the {% data variables.product.prodname_cli %}. +* If your source is Azure DevOps, GitLab, or Bitbucket, the `inventory-report` command for {% data variables.product.prodname_importer_proper_name %}. +* For other migration origins, you could build the spreadsheet using the origin’s reporting tools or API, or you could create the inventory manually. + +You will find detailed information on using these tools in our documentation for the specific migration path. Whatever approach you choose for your migration inventory, make a note of the process you followed or commands you ran. It’s very likely that you’ll want to re-run your inventory as you continue to plan your migration. @@ -144,14 +154,6 @@ To learn more about expert-led migrations, contact your account representative o {% data reusables.migrations.about-migration-paths %} For more information, see [AUTOTITLE](/migrations/overview/migration-paths-to-github). -## Designing your organization structure for the migration destination - -In {% data variables.product.prodname_dotcom %}, each repository belongs to an organization. {% data reusables.organizations.short-summary %} For more information, see [AUTOTITLE](/organizations/collaborating-with-groups-in-organizations/about-organizations). - -Whether you’re adopting {% data variables.product.prodname_dotcom %} for the first time or already using {% data variables.product.prodname_dotcom %}, pause to consider the most effective structure for your organizations and repositories after your migration. The design you choose can maximize collaboration and discovery and minimize administrative burden, or it can create unnecessary silos and administrative overhead. - -We recommend that you minimize the number of organizations and structure them according to one of five archetypes. For detailed guidance, see [AUTOTITLE](/admin/concepts/enterprise-best-practices/organize-work). - ## Performing a dry run migration for every repository Before you continue planning, perform a dry run migration including all of your repositories. Comprehensive dry runs allow you to: @@ -208,11 +210,3 @@ The way that attribution works differs between tools: * If you’re using `ghe-migrator`, `gl-exporter`, or `bbs-exporter`, you will decide how you want to attribute data ahead of time and include a mapping file when you import your data. * If you’re using {% data variables.product.prodname_importer_proper_name %} or {% data variables.product.prodname_elm %}, data will be linked to placeholder identities called “mannequins”, and you can assign this history to real users after your data is migrated. For more information, see [AUTOTITLE](/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/reclaiming-mannequins-for-github-enterprise-importer). - -### Managing teams and permissions - -Most customers use teams to manage access to repositories. With teams, instead of giving Mona access to a repository directly, you can add Mona to the Engineering team, and give everyone in the Engineering team access to the repository. For more information, see [AUTOTITLE](/organizations/organizing-members-into-teams/about-teams). - -You can create your teams and add team members before you migrate your repositories. You may want to manage your members through your identity provider (IdP) by linking your teams to IdP groups. For more information, see [AUTOTITLE](/enterprise-cloud@latest/organizations/organizing-members-into-teams/synchronizing-a-team-with-an-identity-provider-group). - -However, you can’t attach your teams to repositories until after you've migrated the repositories. diff --git a/data/features/oauth-token-revocation-grace-period.yml b/data/features/oauth-token-revocation-grace-period.yml new file mode 100644 index 000000000000..59c22790ac96 --- /dev/null +++ b/data/features/oauth-token-revocation-grace-period.yml @@ -0,0 +1,8 @@ +# Reference: https://github.com/github/docs-content/issues/23816 +# Newly created OAuth tokens are protected from revocation for one minute. +# Shipped behind the `prevent_new_token_deletion` feature flag, which is +# disabled by default on GHES. Add a `ghes` version once it ships there. + +versions: + fpt: '*' + ghec: '*' diff --git a/data/features/pull-request-limit.yml b/data/features/pull-request-limit.yml new file mode 100644 index 000000000000..ed4ec82bccde --- /dev/null +++ b/data/features/pull-request-limit.yml @@ -0,0 +1,4 @@ +# Reference: github/releases#10090 and #8830 +versions: + fpt: '*' + ghec: '*' diff --git a/data/release-notes/enterprise-server/3-17/16.yml b/data/release-notes/enterprise-server/3-17/16.yml index c907858fc154..4be0ef4cd8a1 100644 --- a/data/release-notes/enterprise-server/3-17/16.yml +++ b/data/release-notes/enterprise-server/3-17/16.yml @@ -64,5 +64,3 @@ sections: When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | Git versions are mismatched between containers on the instance. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-17/17.yml b/data/release-notes/enterprise-server/3-17/17.yml index 4b646b3faa39..afb9a2d7988b 100644 --- a/data/release-notes/enterprise-server/3-17/17.yml +++ b/data/release-notes/enterprise-server/3-17/17.yml @@ -82,5 +82,3 @@ sections: When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | Git versions are mismatched between containers on the instance. - - | - Administrators upgrading to certain patch releases encountered a `Failed to generate an OIDC token` error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-17/18.yml b/data/release-notes/enterprise-server/3-17/18.yml index 576a00fa6a30..07baea8169fc 100644 --- a/data/release-notes/enterprise-server/3-17/18.yml +++ b/data/release-notes/enterprise-server/3-17/18.yml @@ -87,5 +87,3 @@ sections: When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | Git versions are mismatched between containers on the instance. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-17/19.yml b/data/release-notes/enterprise-server/3-17/19.yml index 9e458f2987fd..52ffd151f03f 100644 --- a/data/release-notes/enterprise-server/3-17/19.yml +++ b/data/release-notes/enterprise-server/3-17/19.yml @@ -76,5 +76,3 @@ sections: When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | Git versions are mismatched between containers on the instance. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-18/10.yml b/data/release-notes/enterprise-server/3-18/10.yml index 7c2aa4471c5c..6a57ea0c2a96 100644 --- a/data/release-notes/enterprise-server/3-18/10.yml +++ b/data/release-notes/enterprise-server/3-18/10.yml @@ -72,5 +72,3 @@ sections: The setting to define private registries at the organization level for code scanning is only available if dependabot is also enabled for the instance. - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-18/11.yml b/data/release-notes/enterprise-server/3-18/11.yml index 5da2869fe098..d79ebb3b6c64 100644 --- a/data/release-notes/enterprise-server/3-18/11.yml +++ b/data/release-notes/enterprise-server/3-18/11.yml @@ -88,5 +88,3 @@ sections: Custom NTP settings are removed during the upgrade process. - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-18/12.yml b/data/release-notes/enterprise-server/3-18/12.yml index ffb24c202111..be2ff48e7506 100644 --- a/data/release-notes/enterprise-server/3-18/12.yml +++ b/data/release-notes/enterprise-server/3-18/12.yml @@ -93,5 +93,3 @@ sections: Custom NTP settings are removed during the upgrade process. - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-18/13.yml b/data/release-notes/enterprise-server/3-18/13.yml index 9b72ca97ca4f..ba7ab313d4c8 100644 --- a/data/release-notes/enterprise-server/3-18/13.yml +++ b/data/release-notes/enterprise-server/3-18/13.yml @@ -88,5 +88,3 @@ sections: Custom NTP settings are removed during the upgrade process. - | When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-19/10.yml b/data/release-notes/enterprise-server/3-19/10.yml index 522d7e5d3d17..6ae22baa71a1 100644 --- a/data/release-notes/enterprise-server/3-19/10.yml +++ b/data/release-notes/enterprise-server/3-19/10.yml @@ -94,5 +94,3 @@ sections: An issue in the Management Console means the Backups (Preview) and Updates tabs may fail to open and instead return an Internal Server Error. We recommend using the command line interface (CLI) for backups and updates. - | When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-19/7.yml b/data/release-notes/enterprise-server/3-19/7.yml index 949f9b6d1e01..d216d18a2dfd 100644 --- a/data/release-notes/enterprise-server/3-19/7.yml +++ b/data/release-notes/enterprise-server/3-19/7.yml @@ -74,5 +74,3 @@ sections: An issue in the Management Console means the Backups (Preview) and Updates tabs may fail to open and instead return an Internal Server Error. We recommend using the command line interface (CLI) for backups and updates. - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-19/8.yml b/data/release-notes/enterprise-server/3-19/8.yml index 6f370d778699..b1bc54c94afc 100644 --- a/data/release-notes/enterprise-server/3-19/8.yml +++ b/data/release-notes/enterprise-server/3-19/8.yml @@ -92,5 +92,3 @@ sections: An issue in the Management Console means the Backups (Preview) and Updates tabs may fail to open and instead return an Internal Server Error. We recommend using the command line interface (CLI) for backups and updates. - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-19/9.yml b/data/release-notes/enterprise-server/3-19/9.yml index 69f5ea94a256..f942eea70f95 100644 --- a/data/release-notes/enterprise-server/3-19/9.yml +++ b/data/release-notes/enterprise-server/3-19/9.yml @@ -103,5 +103,3 @@ sections: An issue in the Management Console means the Backups (Preview) and Updates tabs may fail to open and instead return an Internal Server Error. We recommend using the command line interface (CLI) for backups and updates. - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-20/3.yml b/data/release-notes/enterprise-server/3-20/3.yml index b14fd04bb040..90be1491d100 100644 --- a/data/release-notes/enterprise-server/3-20/3.yml +++ b/data/release-notes/enterprise-server/3-20/3.yml @@ -64,5 +64,3 @@ sections: When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | On instances with multiple Git storage nodes in a voting configuration, including cluster and geo-replication high availability topologies, upgrading may fail to correctly install Actions that ship with the new version. In some cases, previous versions of these Actions remain on the instance. To resolve this issue, run the following commands on the primary node: `ghe-config --unset 'app.actions.actions-repos-sha1sum'`, `ghe-config-apply`, and `/usr/local/share/enterprise/ghe-run-init-actions-graph`. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-20/4.yml b/data/release-notes/enterprise-server/3-20/4.yml index 0cbe8f02986b..b84a637afcd0 100644 --- a/data/release-notes/enterprise-server/3-20/4.yml +++ b/data/release-notes/enterprise-server/3-20/4.yml @@ -84,5 +84,3 @@ sections: When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | On instances with multiple Git storage nodes in a voting configuration, including cluster and geo-replication high availability topologies, upgrading may fail to correctly install Actions that ship with the new version. In some cases, previous versions of these Actions remain on the instance. To resolve this issue, run the following commands on the primary node: `ghe-config --unset 'app.actions.actions-repos-sha1sum'`, `ghe-config-apply`, and `/usr/local/share/enterprise/ghe-run-init-actions-graph`. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-20/5.yml b/data/release-notes/enterprise-server/3-20/5.yml index 08a539de8675..bb701d25beca 100644 --- a/data/release-notes/enterprise-server/3-20/5.yml +++ b/data/release-notes/enterprise-server/3-20/5.yml @@ -99,5 +99,3 @@ sections: When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | On instances with multiple Git storage nodes in a voting configuration, including cluster and geo-replication high availability topologies, upgrading may fail to correctly install Actions that ship with the new version. In some cases, previous versions of these Actions remain on the instance. To resolve this issue, run the following commands on the primary node: `ghe-config --unset 'app.actions.actions-repos-sha1sum'`, `ghe-config-apply`, and `/usr/local/share/enterprise/ghe-run-init-actions-graph`. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/release-notes/enterprise-server/3-20/6.yml b/data/release-notes/enterprise-server/3-20/6.yml index f7547c5e9865..24324c9aa6d7 100644 --- a/data/release-notes/enterprise-server/3-20/6.yml +++ b/data/release-notes/enterprise-server/3-20/6.yml @@ -90,5 +90,3 @@ sections: When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | On instances with multiple Git storage nodes in a voting configuration, including cluster and geo-replication high availability topologies, upgrading may fail to correctly install Actions that ship with the new version. In some cases, previous versions of these Actions remain on the instance. To resolve this issue, run the following commands on the primary node: `ghe-config --unset 'app.actions.actions-repos-sha1sum'`, `ghe-config-apply`, and `/usr/local/share/enterprise/ghe-run-init-actions-graph`. - - | - Administrators upgrading to certain patch releases encountered a "Failed to generate an OIDC token" error during the `Update Servicing Resources` step when GitHub Actions was configured with Google Cloud Storage (GCS) or AWS S3 using OpenID Connect (OIDC) authentication. The upgrade was blocked and could not complete. To work around this issue, administrators could apply a manual patch by running `sudo sed -i.bak 's|ghe-actions-console -s -c Update-Service|ghe-actions-console -s --no-blob-creds -c Update-Service|g' /usr/local/bin/ghe-actions-update` followed by `ghe-config-apply`. diff --git a/data/reusables/apps/oauth-token-limit.md b/data/reusables/apps/oauth-token-limit.md index 41abaaab9531..39e50b7be0b2 100644 --- a/data/reusables/apps/oauth-token-limit.md +++ b/data/reusables/apps/oauth-token-limit.md @@ -1 +1,16 @@ -There is a limit of ten tokens that are issued per user/application/scope combination, and a rate limit of ten tokens created per hour. If an application creates more than ten tokens for the same user and the same scopes, the oldest tokens with the same user/application/scope combination are revoked. However, hitting the hourly rate limit will not revoke your oldest token. Instead, it will trigger a re-authorization prompt within the browser, asking the user to double check the permissions they're granting your app. This prompt is intended to give a break to any potential infinite loop the app is stuck in, since there's little to no reason for an app to request ten tokens from the user within an hour. +There is a limit of ten tokens that are issued per user/application/scope combination, and a rate limit of ten tokens created per hour. If an application creates more than ten tokens for the same user and the same scopes, {% data variables.product.github %} revokes one of the existing tokens with the same user/application/scope combination, chosen in this order: + +{% ifversion oauth-token-revocation-grace-period %} + +1. The oldest token that has never been used and that was created more than one minute ago. Tokens created within the last minute are usually protected, so that an application has time to use a token it has just created. +1. If there is no such token, but at least one token has been used, the token that was least recently used. +1. If no token has ever been used, the oldest token, even if it was created within the last minute. + +{% else %} + +1. The oldest token that has never been used. +1. If every token has been used, the token that was least recently used. + +{% endif %} + +Hitting the hourly rate limit will not revoke your oldest token. Instead, it will trigger a re-authorization prompt within the browser, asking the user to double check the permissions they're granting your app. This prompt is intended to give a break to any potential infinite loop the app is stuck in, since there's little to no reason for an app to request ten tokens from the user within an hour. diff --git a/data/reusables/copilot/agentic-workflows-third-party-agent-clis.md b/data/reusables/copilot/agentic-workflows-third-party-agent-clis.md new file mode 100644 index 000000000000..f33a0a931eda --- /dev/null +++ b/data/reusables/copilot/agentic-workflows-third-party-agent-clis.md @@ -0,0 +1 @@ +Claude Code, {% data variables.product.prodname_openai_codex %}, or Google {% data variables.copilot.copilot_gemini %} CLI