Merge pull request #38718 from github/repo-sync

Repo sync

Author: docs-bot

.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 %}