Repo sync

.github/copilot-instructions.md

@@ -15,3 +15,11 @@ Within Markdown files, with the exception of the `title` field in the metadata a
 | `{% data variables.code-scanning.codeql_workflow %}` | CodeQL analysis workflow | data/variables/code-scanning.yml | 
 
 There are many more variables. These are stored in various YAML files within the `data/variables` directory.
+
+### Links to other articles
+
+`[AUTOTITLE]` is the correct way to specify the title of a linked article, when that article is another page on the docs.github.com site. Do not suggest replacing the placeholder link text `[AUTOTITLE]` with the actual page title or using the `{% link %}` Liquid tag.
+
+### Creating a pull request
+
+When creating a pull request as a result of a request to do so in Copilot Chat, the first line of the PR description should always be the following (in italics): `_This pull request was created as a result of the following prompt in Copilot Chat._` Then, within a collapsed section, quote the original prompt from Copilot Chat.

content/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-web-commit-signing.md

@@ -23,6 +23,18 @@ If you enable web commit signing, {% data variables.product.prodname_ghe_server
 
 You can enable web commit signing, rotate the private key used for web commit signing, and disable web commit signing.
 
+{% ifversion ghes > 3.16 %}
+
+### About persistent commit signature verification
+
+Persistent commit signature verification is related but separate from web commit signing. This feature ensures that the verified status of commits is retained, even if signing keys are changed or revoked.
+
+Persistent commit signature verification helps maintain long-term integrity and trust in your repository’s commit history. However, you may choose to disable it in environments where minimizing disk usage is a priority, especially for large installations with a high number of verified commits.
+
+For information about disabling persistent commit signature verification, see [AUTOTITLE](/admin/configuring-settings/configuring-user-applications-for-your-enterprise/disabling-persistent-commit-verification).
+
+{% endif %}
+
 ## Enabling web commit signing
 
 {% data reusables.enterprise_site_admin_settings.create-pgp-key-web-commit-signing %}

content/admin/configuring-settings/configuring-user-applications-for-your-enterprise/disabling-persistent-commit-verification.md

@@ -0,0 +1,55 @@
+---
+title: Disabling persistent commit verification
+shortTitle: Disable persistent commit verification
+intro: 'You can disable persistent commit verification on {% data variables.product.prodname_ghe_server %} to reduce disk usage.'
+versions:
+  ghes: '>=3.17'
+type: how_to
+topics:
+  - Access management
+  - Enterprise
+  - Fundamentals
+  - Identity
+  - Security
+permissions: 'Site administrators'
+---
+
+## About persistent commit verification
+
+When persistent commit verification is enabled, {% data variables.product.prodname_ghe_server %} stores a verification record alongside each commit when its signature is verified. This record ensures that verified commits maintain their verification status even if signing keys are later rotated, expired, or revoked. For more information about persistent commit verification, see [AUTOTITLE](/authentication/managing-commit-signature-verification/about-commit-signature-verification#persistent-commit-signature-verification).
+
+By default, persistent commit verification is enabled on {% data variables.product.prodname_ghe_server %} 3.17 and later.
+
+Each verified commit requires approximately 80 bytes of storage. For large installations with a large number of verified commits (e.g., hundreds of thousands or more), you may want to disable this feature to limit data growth.
+
+## Disabling persistent commit verification
+
+You can disable persistent commit verification for {% data variables.location.product_location %}.
+
+1. In the administrative shell, run the following command.
+
+   ```bash copy
+   ghe-config app.persist-commit-signature-verification.enabled false
+   ```
+
+1. Apply the configuration.
+
+   ```bash copy
+   ghe-config-apply
+   ```
+
+## Enabling persistent commit verification
+
+If you previously disabled persistent commit verification, you can re-enable it.
+
+1. In the administrative shell, run the following command.
+
+   ```bash copy
+   ghe-config app.persist-commit-signature-verification.enabled true
+   ```
+
+1. Apply the configuration.
+
+   ```bash copy
+   ghe-config-apply
+   ```

content/admin/configuring-settings/configuring-user-applications-for-your-enterprise/index.md

@@ -16,6 +16,7 @@ children:
   - /configuring-interactive-maps
   - /managing-github-mobile-for-your-enterprise
   - /verifying-or-approving-a-domain-for-your-enterprise
+  - /disabling-persistent-commit-verification
 redirect_from:
   - /admin/configuration/configuring-user-applications-for-your-enterprise
 ---

content/admin/managing-iam/provisioning-user-accounts-with-scim/configuring-scim-provisioning-with-okta.md

@@ -120,7 +120,16 @@ Before starting this section, ensure you have followed steps **1 to 4** in [AUTO
 1. Click **Configure API integration**.
 1. In the "API Token" field, enter the {% data variables.product.pat_v1 %} belonging to the setup user.
 
-   {% data reusables.scim.import-groups-unsupported %}
+    {% data reusables.scim.import-groups-unsupported %}
+
+    {% ifversion ghec %}
+
+    > [!IMPORTANT]
+    > For an enterprise on {% data variables.enterprise.data_residency %} (GHE.com), please enter the following URL in the **Base URL** field: {% raw %}`https://api.{subdomain}.ghe.com/scim/v2/enterprises/{subdomain}`{% endraw %} (ensuring to replace {% raw %}`{subdomain}`{% endraw %} with your enterprise's subdomain).
+    >
+    > **For example**: if your enterprise's subdomain is {% raw %}`acme`{% endraw %}, the base URL would be {% raw %}`https://api.acme.ghe.com/scim/v2/enterprises/acme`{% endraw %}.
+
+    {% endif %}
 
 1. Click **Test API Credentials**. If the test is successful, a verification message will appear at the top of the screen.
 1. To save the token, click **Save**.

content/admin/managing-iam/understanding-iam-for-enterprises/getting-started-with-enterprise-managed-users.md

@@ -39,7 +39,10 @@ Using an **incognito or private browsing window**:
 1. Enable two-factor authentication (2FA), and save the recovery codes. See [AUTOTITLE](/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication).
 
    > [!WARNING]
-   > All subsequent login attempts for the setup user account will require a successful 2FA challenge response or the use of an enterprise recovery code to complete authentication. To avoid being locked out of your account, after enabling single sign-on, save your enterprise recovery codes. See [AUTOTITLE](/admin/managing-iam/managing-recovery-codes-for-your-enterprise/downloading-your-enterprise-accounts-single-sign-on-recovery-codes#downloading-codes-for-an-enterprise-with-enterprise-managed-users).
+   > All subsequent login attempts for the setup user account will require a successful 2FA challenge response.
+
+   > [!IMPORTANT]
+   > If the enterprise account has enabled single sign-on and the setup user hasn’t enabled 2FA, they must use an enterprise recovery code to authenticate. To avoid being locked out of your account, after enabling single sign-on, save your enterprise recovery codes. For more information, see [AUTOTITLE](/admin/managing-iam/managing-recovery-codes-for-your-enterprise/downloading-your-enterprise-accounts-single-sign-on-recovery-codes#downloading-codes-for-an-enterprise-with-enterprise-managed-users) and the related [changelog in our {% data variables.product.prodname_blog %}](https://github.blog/changelog/2025-01-17-setup-user-for-emu-enterprises-requires-2fa-or-use-of-a-recovery-code/).
 
 {% data reusables.enterprise-accounts.emu-password-reset-session %}
 

content/admin/monitoring-and-managing-your-instance/monitoring-your-instance/exporting-and-scraping-prometheus-metrics.md

@@ -53,7 +53,7 @@ curl -L -H "Content-Type: application/json" -X PUT -u "api_key:xxxxxxx" https://
 To verify that the Prometheus metrics exporter is enabled, use `curl` to query the `/metrics` endpoint on port 9103. For more information about the administrative ports, see [AUTOTITLE](/admin/configuring-settings/configuring-network-settings/network-ports#administrative-ports).
 
 ```shell
-curl localhost:9103/metrics
+curl 127.0.0.1:9103/metrics
 ```
 
 If successful, the response will include metrics with the `collectd_` prefix.

content/admin/upgrading-your-instance/preparing-to-upgrade/overview-of-the-upgrade-process.md

@@ -80,7 +80,7 @@ Check if you need to upgrade the following applications:
     > [!NOTE]
     > Hotpatches require a configuration run, which can cause a brief period of errors or unresponsiveness for some or all services on {% data variables.location.product_location %}. You are not required to enable maintenance mode during installation of a hotpatch, but doing so will guarantee that users see a maintenance page instead of errors or timeouts. See [AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode).
   * Patch releases using an upgrade package typically require less than five minutes of downtime.
-  * Upgrading to a new feature release that include data migrations may cause a few hours of downtime, depending on storage performance and the amount of data that is migrated. During this time none of your users will be able to use the enterprise.
+  * Upgrading to a new feature release that includes data migrations may cause a few hours of downtime, depending on storage performance and the amount of data that is migrated. During this time none of your users will be able to use the enterprise.{% ifversion ghes > 3.16 %} You may notice that upgrades to a new feature release take less time. This is because selective database transitions will now run concurrently, with the number of concurrent workers defaulting to the number of CPU cores, up to a maximum of 16.{% endif %}
 
 ## Communicating your upgrade
 

content/authentication/managing-commit-signature-verification/about-commit-signature-verification.md

@@ -42,6 +42,10 @@ Signing commits differs from signing off on a commit. For more information about
 | **Unverified** | The commit is signed but the signature could not be verified.
 | No verification status | The commit is not signed.
 
+{% endif %}
+
+{% ifversion fpt or ghec or ghes > 3.16 %}
+
 ### Persistent commit signature verification
 
 Regardless of the signature choice - GPG, SSH, or S/MIME - once a commit signature is verified, it remains verified within its repository's network. See [AUTOTITLE](/repositories/viewing-activity-and-data-for-your-repository/understanding-connections-between-repositories).
@@ -52,6 +56,12 @@ The verification record includes a timestamp marking when the verification was c
 
 Persistent commit signature verification applies to new commits pushed to {% data variables.product.github %}. For any commits that predate this feature, a persistent record will be created the next time the commit's signature is verified on {% data variables.product.github %}, helping ensure that verified statuses remain stable and reliable across the repository's history.
 
+{% ifversion ghes %}
+
+For information about disabling persistent commit signature verification, see [AUTOTITLE](/admin/configuring-settings/configuring-user-applications-for-your-enterprise/disabling-persistent-commit-verification).
+
+{% endif %}
+
 #### Records persist even after revocation and expiration
 
 Persistent commit signature verification reflects the verified state of a commit at the time of verification. This means that if a signing key is later revoked, expired, or otherwise altered, previously verified commits retain their verified status based on the record created during the initial verification. {% data variables.product.github %} will not re-verify previously signed commits or retroactively adjust their verification status in response to changes in the key's state. Organizations may need to manage key states directly to align with their security policies, especially if frequent key rotation or revocation is planned.

content/billing/managing-billing-for-your-products/managing-billing-for-github-advanced-security/migrating-from-ghas-to-cs-and-sp.md

@@ -18,13 +18,11 @@ shortTitle: Migrating to new GHAS SKUs
 
 ## New SKUs for {% data variables.product.prodname_AS %} features
 
-<!-- expires 2025-05-31 -->
+<!-- expires 2025-09-30 -->
 
-<!-- On expiry, check with the stakeholder. If nothing else, remove the date from the start of this paragraph and check the information for Metered-billing users is still appropriate. Possibly the whole article can be deleted. Reference: release 5202 -->
+{% data variables.product.prodname_AS %} features are also available under two separate stock keeping units (SKUs) for {% data variables.product.prodname_team %} and {% data variables.product.prodname_ghe_cloud %} users. {% data variables.product.prodname_ghe_server %} users can use the two new SKUs when upgrading to version 3.17.
 
-From April 1, 2025, {% data variables.product.prodname_AS %} features are also available under two separate stock keeping units (SKUs) for {% data variables.product.prodname_team %} and {% data variables.product.prodname_ghe_cloud %} users. {% data variables.product.prodname_ghe_server %} users can use the two new SKUs when upgrading to version 3.17.
-
-<!-- end expires 2025-05-31 -->
+<!-- end expires 2025-09-30 -->
 
 {% data reusables.advanced-security.ghas-products-bullets %}
 

content/code-security/dependabot/working-with-dependabot/dependabot-options-reference.md

@@ -395,7 +395,7 @@ Package manager | YAML value      | Supported versions |
 | pip| `pip`            | v21.1.2          |
 | pip-compile | `pip`            | 6.1.0            |
 | pipenv         | `pip`            | <= 2021-05-29    |
-| pnpm   | `npm`            | v7, v8 <br>v9 (version updates only)    |
+| pnpm   | `npm`            | v7, v8 <br>v9, v10 (version updates only)    |
 | poetry         | `pip`            | v2               |
 | pub         | `pub`            | v2  |
 | Swift   | `swift`      | v5  |

content/code-security/secret-scanning/introduction/supported-secret-scanning-patterns.md

@@ -51,9 +51,12 @@ This table lists the secrets supported by {% data variables.product.prodname_sec
 
 {% data reusables.secret-scanning.non-provider-patterns-beta %}
 
+{% ifversion secret-scanning-ai-generic-secret-detection %}
+In addition to these generic non-provider patterns, {% data variables.product.prodname_secret_scanning %} uses {% data variables.product.prodname_copilot_short %} to detect generic passwords. For more information, see [AUTOTITLE](/code-security/secret-scanning/copilot-secret-scanning/responsible-ai-generic-secrets).
+{% endif %}
+
 | Provider | Token |
 |----------|:--------------------|
-|  Generic | password |
 |  Generic | http_basic_authentication_header |
 |  Generic | http_bearer_authentication_header |
 |  Generic | mongodb_connection_string |

content/code-security/securing-your-organization/enabling-security-features-in-your-organization/applying-the-github-recommended-security-configuration-in-your-organization.md

@@ -17,7 +17,7 @@ topics:
 The {% data variables.product.prodname_github_security_configuration %} is a collection of enablement settings for {% data variables.product.company_short %}'s security features that is created and maintained by subject matter experts at {% data variables.product.company_short %}. The {% data variables.product.prodname_github_security_configuration %} is designed to successfully reduce the security risks for low- and high-impact repositories. We recommend you apply this configuration to all the repositories in your organization.
 
 > [!NOTE]
-> The {% data variables.product.prodname_github_security_configuration %} includes {% data variables.product.prodname_GH_code_security %} and {% data variables.product.prodname_GH_secret_protection %} features. Applying the configuration to repositories in your organization will incur usage costs or require licenses.
+> The {% data variables.product.prodname_github_security_configuration %} includes {% data variables.product.prodname_GH_code_security %} and {% data variables.product.prodname_GH_secret_protection %} features. Applying the configuration to private and internal repositories in your organization will incur usage costs or require licenses.
 
 ## Applying the {% data variables.product.prodname_github_security_configuration %} to all repositories in your organization
 

content/code-security/securing-your-organization/enabling-security-features-in-your-organization/giving-org-access-private-registries.md

@@ -17,12 +17,12 @@ When a repository uses code stored in a private registry, some security features
 
 ## {% data variables.product.prodname_code_scanning_caps %} default setup access to private registries
 
-{% data variables.product.prodname_code_scanning_caps %} default setup analyzes {% data variables.code-scanning.no_build_support %} code without building it. If you do not define access to the private registries your organization uses, then {% data variables.product.prodname_code_scanning %} will only gather necessary data from dependencies available in public registries. Most times, this is enough for surfacing most of the vulnerabilities. However, in some cases the lack of access can lead to false negative results, that is, {% data variables.product.prodname_code_scanning %} is unable to detect a vulnerability in the code because it does not have all the information it needs to analyze the code. For example, some of the data flow paths may not be detected because steps are defined in dependencies that are not accessible and {% data variables.product.prodname_code_scanning %} does not know how to interpret them.
+If you do not define access to the private registries your organization uses, then {% data variables.product.prodname_code_scanning %} will only gather necessary data from dependencies available in public registries. Most times, this is enough for surfacing most of the vulnerabilities. However, in some cases the lack of access can lead to false negative results, that is, {% data variables.product.prodname_code_scanning %} is unable to detect a vulnerability in the code because it does not have all the information it needs to analyze the code. For example, some of the data flow paths may not be detected because steps are defined in dependencies that are not accessible and {% data variables.product.prodname_code_scanning %} does not know how to interpret them.
 
 When you configure access to the private registries used in your organization, {% data variables.product.prodname_code_scanning %} has access to all the information it needs and is much less likely to miss a vulnerability.
 
 > [!TIP]
-> You can define one private Maven registry and one private NuGet feed for each organization. If the codebases in your organization use more than one registry or feed, you should define access to the most important registry for the codebases in that organization.
+> You can define one of each type of registry for each organization. If the codebases in your organization use more than one registry of a given type, you should define access to the most important registry for the codebases in that organization.
 
 ### Defining registry access for {% data variables.product.prodname_code_scanning %} default setup
 

content/code-security/securing-your-organization/introduction-to-securing-your-organization-at-scale/choosing-a-security-configuration-for-your-repositories.md

@@ -31,7 +31,7 @@ The {% data variables.product.prodname_github_security_configuration %} offers a
 * It is the quickest {% data variables.product.prodname_security_configuration %} to apply to all repositories in your organization.
 * It is designed to effectively secure both low- and high-impact repositories.
 
-The {% data variables.product.prodname_github_security_configuration %} includes {% data variables.product.prodname_GH_code_security %} and {% data variables.product.prodname_GH_secret_protection %} features. Applying the configuration to repositories in your organization will incur usage costs or require licenses.
+The {% data variables.product.prodname_github_security_configuration %} includes {% data variables.product.prodname_GH_code_security %} and {% data variables.product.prodname_GH_secret_protection %} features. Applying the configuration to private and internal repositories in your organization will incur usage costs or require licenses.
 
 To start securing repositories in your organization with the {% data variables.product.prodname_github_security_configuration %}, see [AUTOTITLE](/code-security/securing-your-organization/enabling-security-features-in-your-organization/applying-the-github-recommended-security-configuration-in-your-organization).