Repo sync

content/admin/upgrading-your-instance/troubleshooting-upgrades/index.md

@@ -6,5 +6,6 @@ versions:
 children:
   - /restoring-from-a-failed-upgrade
   - /known-issues-with-upgrades-to-your-instance
+  - /rotating-the-signing-key-for-upgrade-packages
 shortTitle: Troubleshoot an upgrade
 ---

content/admin/upgrading-your-instance/troubleshooting-upgrades/known-issues-with-upgrades-to-your-instance.md

@@ -17,6 +17,8 @@ category:
 
 {% data variables.product.company_short %} is aware of the following issues that could impact upgrades to new releases of {% data variables.product.prodname_ghe_server %}. For more information, see "Known issues" in the [{% data variables.product.prodname_ghe_server %} release notes](/admin/release-notes).
 
+If you see the error `The file provided is not a valid GitHub Enterprise Server package` when attempting an upgrade, you may need to rotate the GPG signing key on your instance. For more information, see [AUTOTITLE](/admin/upgrading-your-instance/troubleshooting-upgrades/rotating-the-signing-key-for-upgrade-packages).
+
 {% data variables.product.company_short %} strongly recommends regular backups of your instance's configuration and data. Before you proceed with any upgrade, back up your instance, then validate the backup in a staging environment. For more information, see [AUTOTITLE](/admin/configuration/configuring-your-enterprise/configuring-backups-on-your-appliance) and [AUTOTITLE](/admin/installation/setting-up-a-github-enterprise-server-instance/setting-up-a-staging-instance).
 
 ## Lifting the pause on upgrades to version 3.15 and above

content/admin/upgrading-your-instance/troubleshooting-upgrades/rotating-the-signing-key-for-upgrade-packages.md

@@ -0,0 +1,99 @@
+---
+title: Rotating the signing key for upgrade packages
+intro: 'Learn how to rotate the GPG public key on {% data variables.product.prodname_ghe_server %} when {% data variables.product.company_short %} updates the key used to sign upgrade packages.'
+versions:
+  ghes: '*'
+shortTitle: Rotate upgrade signing key
+contentType: how-tos
+category:
+  - Back up and upgrade your instance
+---
+
+## About upgrade package signing keys
+
+{% data variables.product.prodname_ghe_server %} upgrade packages are signed with a GPG key so that administrators can verify the packages come from {% data variables.product.company_short %}. When you install an upgrade, the appliance checks the package signature against the GPG public key stored in its keyring.
+
+Occasionally, {% data variables.product.company_short %} may rotate this signing key. When that happens, you must update the GPG public key on your instance before you can install any upgrade packages signed with the new key. Your instance will continue to function normally without the key rotation, but upgrades will fail signature verification until the key is updated.
+
+If the signing key has not been rotated, attempting to install an upgrade package will fail with the following error:
+
+```text
+Error: The file provided is not a valid GitHub Enterprise Server package.
+```
+
+## Considerations for unsupported versions
+
+{% data variables.product.company_short %} strongly recommends upgrading to a supported version as soon as possible.
+
+Versions of {% data variables.product.prodname_ghe_server %} prior to 3.16 are not being re-signed with the new GPG key. If you are on version 3.13 or earlier you will not be able to rotate the GPG public key until you are on at least version 3.14. If you rotate your GPG public key before upgrading to at least 3.14 you will not be able to install upgrades, as the prior GPG public key will be removed from your {% data variables.product.prodname_ghe_server %} instance.
+
+For help determining the correct upgrade path, use the [{% data variables.enterprise.upgrade_assistant %}](https://support.github.com/enterprise/server-upgrade).
+
+## Prerequisites
+
+* SSH access to your {% data variables.product.prodname_ghe_server %} instance. For more information, see [AUTOTITLE](/admin/administering-your-instance/accessing-the-administrative-shell-ssh).
+* Your instance must be able to reach `enterprise.github.com` over HTTPS to download the rotation script. If your instance is behind a restrictive firewall or in an air-gapped environment, download the script from an external machine and transfer it to the appliance manually.
+
+## Rotating the signing key on a single-node instance
+
+1. Connect to your {% data variables.product.prodname_ghe_server %} instance via SSH.
+1. Download the rotation script provided by {% data variables.product.company_short %}.
+
+   ```shell
+   curl -fsSL https://enterprise.github.com/security/2026-05-24/rotate-gpg.sh -o rotate-gpg.sh
+   ```
+
+1. Run the rotation script. The script must be run twice: once as the `admin` user and once with `sudo`, because the key is stored in both the admin and root accounts.
+
+   ```shell
+   chmod ug+x ./rotate-gpg.sh
+   ./rotate-gpg.sh
+   sudo ./rotate-gpg.sh
+   ```
+
+1. Verify the rotation completed successfully. Each run of the script prints a confirmation message that includes the new key fingerprint.
+
+## Rotating the signing key on HA or cluster topologies
+
+For instances configured with high availability or clustering, the key must be rotated on every node.
+
+1. Connect to any node in your HA or cluster installation via SSH.
+1. Download the rotation script provided by {% data variables.product.company_short %}.
+
+   ```shell
+   curl -fsSL https://enterprise.github.com/security/2026-05-24/rotate-gpg.sh -o rotate-gpg.sh
+   ```
+
+1. Run the following commands. The `ghe-cluster-each` command copies the script to all nodes and runs it on all nodes.
+
+   ```shell
+   ghe-cluster-each -- chmod ug+x ./rotate-gpg.sh
+   ghe-cluster-each -- ./rotate-gpg.sh
+   ghe-cluster-each -- sudo ./rotate-gpg.sh
+   ```
+
+1. Verify the rotation completed successfully on each node.
+
+## Verifying the current signing key
+
+To check which GPG signing key is currently installed on your instance, connect via SSH and run:
+
+```shell
+gpg --list-keys --keyid-format long
+```
+
+The output displays the fingerprint of the key in the keyring. Compare the fingerprint with the expected value published by {% data variables.product.company_short %} to confirm the rotation was applied correctly.
+
+## What to expect after rotating the key
+
+After you rotate the signing key:
+
+* Your instance continues to function normally. No user downtime is required.
+* Previously downloaded upgrade packages that were signed with the prior key will fail verification. Download the latest available patch release to get a package signed with the new key.
+* Only download {% data variables.product.prodname_ghe_server %} updates from the official releases page. For more information, see [{% data variables.product.prodname_ghe_server %} releases](https://enterprise.github.com/releases).
+
+## Reverting a key rotation
+
+The rotation script removes the previous key from the GPG keyring before importing the new key. There is no built-in way to undo the rotation.
+
+If you need assistance reverting a key rotation or recovering from a failed upgrade, [contact {% data variables.contact.github_support %}](/support/contacting-github-support).

content/copilot/concepts/billing/usage-based-billing-for-individuals.md

@@ -18,7 +18,7 @@ redirect_from:
   - /copilot/how-tos/manage-and-track-spending/prepare-for-your-move-to-usage-based-billing
 ---
 
-{% data variables.product.prodname_copilot_short %} usage is measured in {% data variables.product.prodname_ai_credits_short %}. All {% data variables.product.prodname_copilot_short %} plans include a monthly allowance of {% data variables.product.prodname_ai_credits_short %}. If you use up all of the credits included in your plan, you can purchase more and keep working. 
+{% data variables.product.prodname_copilot_short %} usage is measured in {% data variables.product.prodname_ai_credits_short %}. All {% data variables.product.prodname_copilot_short %} plans include a monthly allowance of {% data variables.product.prodname_ai_credits_short %}. If you use up all of the credits included in your plan, you can purchase more and keep working.
 
 ## What are {% data variables.product.prodname_ai_credits %}?
 
@@ -105,6 +105,30 @@ Your billing date will depend on whether or not you are already being billed by
 * **If you are not already being billed by {% data variables.product.prodname_dotcom %}**, in most cases your billing cycle will start on the day you sign up for {% data variables.product.prodname_copilot_short %}. For example, if you sign up on 3 September, with monthly billing, your initial billing cycle will run from 3 September until and including 2 October, and then on the same days of subsequent months.
 * **If you already have a billing cycle**, billing for {% data variables.product.prodname_copilot_short %} will be included in your next bill. You will be charged on a pro rata basis for that initial period.
 
+<!-- expires 2026-09-01 -->
+
+## Update your IDE, client, and extension
+
+For the best experience with usage-based billing, update your IDE, client, and {% data variables.product.prodname_copilot_short %} extension to at least the versions listed below.
+
+> [!NOTE]
+> Older versions will continue to work, but may display incorrect model pricing, inaccurate usage information, or outdated billing terminology. Usage alert notifications may also not appear as expected.
+
+| IDE, client, or extension | Minimum version |
+| --- | --- |
+| {% data variables.product.prodname_vscode_shortname %} | 1.120 |
+| {% data variables.product.prodname_vs %} 2022 (17.x) | 17.14.33 |
+| {% data variables.product.prodname_vs %} 2025 (18.x) | 18.6.0 |
+| SQL Server Management Studio | 22.6 |
+| JetBrains IDEs (plugin) | 1.9.1 |
+| Eclipse (plugin) | 0.18.0 |
+| Xcode (extension) | 0.50.0 |
+| {% data variables.copilot.copilot_cli_short %} | 1.0.48 |
+
+We recommend keeping your IDE, client, and {% data variables.product.prodname_copilot_short %} extensions on the latest available stable version. For information on configuring automatic updates, see [AUTOTITLE](/copilot/how-tos/configure-personal-settings/configure-in-ide). To update {% data variables.copilot.copilot_cli_short %}, see [AUTOTITLE](/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli).
+
+<!-- end expires 2026-09-01 -->
+
 ## Further reading
 
 * [AUTOTITLE](/copilot/about-github-copilot/subscription-plans-for-github-copilot)

content/copilot/concepts/billing/usage-based-billing-for-organizations-and-enterprises.md

@@ -77,6 +77,30 @@ Budget controls let you govern how individual users draw from the shared pool an
 
 For a full explanation of how these controls work together and when usage gets blocked, see [AUTOTITLE](/copilot/concepts/billing/budgets-for-usage-based-billing).
 
+<!-- expires 2026-09-01 -->
+
+## Update your IDE, client, and extension
+
+For the best experience with usage-based billing, update your IDE, client, and {% data variables.product.prodname_copilot_short %} extension to at least the versions listed below.
+
+> [!NOTE]
+> Older versions will continue to work, but may display incorrect model pricing, inaccurate usage information, or outdated billing terminology. Usage alert notifications may also not appear as expected.
+
+| IDE, client, or extension | Minimum version |
+| --- | --- |
+| {% data variables.product.prodname_vscode_shortname %} | 1.120 |
+| {% data variables.product.prodname_vs %} 2022 (17.x) | 17.14.33 |
+| {% data variables.product.prodname_vs %} 2025 (18.x) | 18.6.0 |
+| SQL Server Management Studio | 22.6 |
+| JetBrains IDEs (plugin) | 1.9.1 |
+| Eclipse (plugin) | 0.18.0 |
+| Xcode (extension) | 0.50.0 |
+| {% data variables.copilot.copilot_cli_short %} | 1.0.48 |
+
+We recommend keeping your IDE, client, and {% data variables.product.prodname_copilot_short %} extensions on the latest available stable version. For information on configuring automatic updates, see [AUTOTITLE](/copilot/how-tos/configure-personal-settings/configure-in-ide). To update {% data variables.copilot.copilot_cli_short %}, see [AUTOTITLE](/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli).
+
+<!-- end expires 2026-09-01 -->
+
 ## Next steps
 
 * To set up budget controls for your enterprise, see [AUTOTITLE](/copilot/tutorials/budgets/getting-started-with-budget-controls).

content/copilot/reference/copilot-cli-reference/cli-command-reference.md

@@ -301,6 +301,8 @@ For a complete list of commands and options, run `copilot help`.
 > [!NOTE]
 > The `--remote`, `--no-remote`, and `--connect` options require the remote sessions feature to be available on your account.
 
+You can use `--remote` with `--resume <TASK-ID>` to resume a remote task locally. This works even when the task was originally created outside a Git repository.
+
 ## Tool availability values
 
 The `--available-tools` and `--excluded-tools` options support these values:
@@ -541,13 +543,26 @@ The CLI includes built-in MCP servers that are available without additional setu
 
 | Server | Description |
 |--------|-------------|
-| `github-mcp-server` | {% data variables.product.github %} API integration: issues, pull requests, commits, code search, and {% data variables.product.prodname_actions %}. |
+| `github-mcp-server` | {% data variables.product.github %} API integration: issues, pull requests, labels, commits, code search, and {% data variables.product.prodname_actions %}. |
 | `playwright` | Browser automation: navigate, click, type, screenshot, and form handling. |
 | `fetch` | HTTP requests via the `fetch` tool. |
 | `time` | Time utilities: `get_current_time` and `convert_time`. |
 
 Use `--disable-builtin-mcps` to disable all built-in servers, or `--disable-mcp-server SERVER-NAME` to disable a specific one.
 
+#### {% data variables.product.github %} MCP server tools
+
+The `github-mcp-server` provides the following tools.
+
+| Tools | Description |
+|-------|-------------|
+| `get_file_contents`, `search_code` | Browse repository files. |
+| `list_issues`, `issue_read`, `search_issues` | Issue tracking. |
+| `get_pull_request`, `list_pull_requests`, `get_pull_request_files` | Pull requests. |
+| `list_commits`, `get_commit` | Commit history. |
+| `list_workflow_runs`, `get_workflow_run_logs` | {% data variables.product.prodname_actions %}. |
+| `get_label`, `list_label`, `label_write` | Label management. |
+
 ### MCP server naming
 
 Server names can contain any printable characters, including spaces, Unicode characters, and punctuation. Control characters (U+0000–U+001F, U+007F) and the closing brace (`}`) are not allowed. Server names are used as prefixes for tool names—for example, a server named `my-server` produces tool names like `my-server-fetch`, and a server named `My Server` produces `My Server-fetch`.

data/reusables/dependabot/dependabot-updates-supported-versioning-tags.md

@@ -13,10 +13,17 @@ The `dependabot.yml` file doesn't control the versioning tags that you can use,
 | sbt                 | `sbt`          | `alpha, a, beta, b, milestone, m, rc, cr, sp, ga, final, release, snapshot` | `akka-actor@2.7.0-RC1`, `play-json@3.0.0-M1` |
 | {% endif %} |
 | yarn                | `npm`          | `alpha`, `beta`, `canary`, `dev`, `experimental`, `latest`, `legacy`, `next`, `nightly`, `rc`, `release`, `stable` | `lodash@1.2.0-alpha`, `axios@latest`, `moment@nightly` |
-| Bundler             | `bundler`      | `alpha`, `beta`, `rc`, `pre` | `rails@1.0.0.alpha`, `rack@1.0.0.beta1`, `rspec@1.0.0.rc2` |
+| Bundler             | `bundler`      | Any prerelease identifier (commonly `alpha`, `beta`, `rc`, `pre`) | `rails@1.0.0.alpha`, `rack@1.0.0.beta1`, `rspec@1.0.0.rc2` |
+| Cargo               | `cargo`        | Any SemVer prerelease identifier (commonly `alpha`, `beta`, `rc`, `dev`) | `serde@1.0.0-alpha`, `tokio@0.2.0-preview.3`, `clap@4.0.0-rc.1`, `rand@1.0.0-dev` |
+| pip                 | `pip`          | `a`, `b`, `rc`, `dev`, `post` | `requests@1.0.0a1`, `numpy@2.0.0b3`, `django@4.0rc1`, `black@1.0.0.dev5`, `pandas@2.0.5.post1` |
+| pipenv              | `pip`          | `a`, `b`, `rc`, `dev`, `post` | `requests@1.0.0a1`, `numpy@2.0.0b3`, `django@4.0rc1`, `black@1.0.0.dev5`, `pandas@2.0.5.post1` |
+| pip-compile         | `pip`          | `a`, `b`, `rc`, `dev`, `post` | `requests@1.0.0a1`, `numpy@2.0.0b3`, `django@4.0rc1`, `black@1.0.0.dev5`, `pandas@2.0.5.post1` |
+| poetry              | `pip`          | `a`, `b`, `rc`, `dev`, `post` | `requests@1.0.0a1`, `numpy@2.0.0b3`, `django@4.0rc1`, `black@1.0.0.dev5`, `pandas@2.0.5.post1` |
 
 #### Ecosystem-specific versioning details
 
 The following details describe how {% data variables.product.prodname_dependabot %} interprets versioning for specific ecosystems.
 
 * **Bundler:** Bundler does not use a fixed set of prerelease tags. Any version segment containing a letter is treated as a prerelease (for example, `.alpha`, `.beta1`, `.rc2`). Hyphens in version strings are normalized to `.pre.` internally (for example, `1.0.0-beta` becomes `1.0.0.pre.beta`).
+* **Cargo:** Follows SemVer 2.0.0 prerelease conventions. Anything after `-` is a prerelease identifier (dot-separated, `[0-9A-Za-z-]`). Build metadata (`+...`) is allowed but ignored for version precedence.
+* **pip/pipenv/pip-compile/poetry (PEP 440):** The table lists canonical prerelease and postrelease suffixes per PEP 440. Aliases are also recognized and normalized to their canonical forms (`alpha`→`a`, `beta`→`b`, `c`/`pre`/`preview`→`rc`, `rev`/`r`→`post`). Epoch versions (`N!...`) and local versions (`+local`) are supported; local version segments are used only to break ties when the public version is identical.

src/content-pipelines/state/copilot-cli.sha

@@ -1 +1 @@
-e7ee4ef1f3d09323d60d202f335cc24f94d71fa9
+6f4199ecdb5aec16a6caafade77d0aab7352d176