Repo sync

content/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs.md

@@ -21,6 +21,8 @@ Re-runs use the privileges of the actor who initially triggered the workflow, no
 
 A workflow run can be re-run a maximum of 50 times. This limit includes both full re-runs and re-runs of a subset of jobs.
 
+When you re-run failed jobs or a specific job, {% data variables.product.github %} also re-runs the jobs that depend on them. Jobs that aren't included keep their outputs from the previous attempt, which the newly run jobs can use.
+
 You can't re-run a workflow run, or any of its jobs, while the workflow is disabled. You need to enable the workflow first. See [AUTOTITLE](/actions/how-tos/manage-workflow-runs/disable-and-enable-workflows).
 
 ## Re-running all the jobs in a workflow

content/actions/reference/limits.md

@@ -37,7 +37,7 @@ These limits are subject to change.
 | {% ifversion actions-nga %} |
 | Workflows queuing | Concurrency group queue | 100 workflow runs / concurrency group | When using `queue: max` in the `concurrency` section, up to 100 jobs or workflow runs can be queued per concurrency group. Runs beyond this limit will be rejected. | {% octicon "x" aria-label="No" %} |
 | {% endif %} |
-| Self-hosted | Runner registrations | 1500 runners / 5 minutes / repository/org/enterprise | Runners can be registered per repository/organization/enterprise. | {% octicon "check" aria-label="Yes" %} Support ticket |
+| Self-hosted | Runner registrations | 1500 runners / 5 minutes / repository/org/enterprise | Runners can be registered per repository/organization/enterprise. | {% octicon "x" aria-label="No" %} |
 | Self-hosted | Runners per runner group | 10,000 runners | Runners registered at the same time per runner group. | {% octicon "x" aria-label="No" %} |
 | Self-hosted | Job execution time | 5 days | Each job in a workflow can run for up to 5 days of execution time. If a job reaches this limit, the job is terminated and fails. | {% octicon "x" aria-label="No" %} |
 | Self-hosted | Job queue time | 24 hours | A job can be in the queue for 24 hours before it is automatically cancelled. | {% octicon "x" aria-label="No" %} |

content/admin/backing-up-and-restoring-your-instance/configuring-backups-on-your-instance.md

@@ -159,7 +159,7 @@ Network settings are excluded from the backup snapshot. After restoration, you m
 ### Prerequisites
 
 1. Ensure maintenance mode is enabled on the primary instance and all active processes have completed. For more information, see [AUTOTITLE](/admin/administering-your-instance/configuring-maintenance-mode/enabling-and-scheduling-maintenance-mode).
-1. Stop replication on all replica nodes in a high-availability configuration. For more information, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/configuring-high-availability/about-high-availability-configuration#ghe-repl-stop).
+1. Tear down replication on all replica nodes in a high-availability configuration. For more information, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/configuring-high-availability/removing-a-high-availability-replica).
 1. Provision a new {% data variables.product.prodname_ghe_server %} instance to use as a target for the restoration of your backup. For more information, see [AUTOTITLE](/admin/installing-your-enterprise-server/setting-up-a-github-enterprise-server-instance).
 1. If {% data variables.location.product_location %} has {% data variables.product.prodname_actions %} enabled, you must configure the external storage provider for {% data variables.product.prodname_actions %} on the replacement instance. For more information, see [AUTOTITLE](/admin/managing-github-actions-for-your-enterprise/advanced-configuration-and-troubleshooting/backing-up-and-restoring-github-enterprise-server-with-github-actions-enabled).
 

content/admin/backing-up-and-restoring-your-instance/restoring-from-a-backup.md

@@ -30,18 +30,18 @@ You also can’t restore from a newer version to an older one. For example, tryi
 
 Before restoring a backup:
 
-1. **Enable maintenance mode** on the target instance. See [AUTOTITLE](/admin/administering-your-instance/configuring-maintenance-mode/enabling-and-scheduling-maintenance-mode).
-1. **Verify access** to the backup storage containing the snapshot.
+1. **Provision a new {% data variables.product.prodname_ghe_server %} instance** to use as a target for the restoration of your backup. For more information, see [AUTOTITLE](/admin/installing-your-enterprise-server/setting-up-a-github-enterprise-server-instance).
 1. **Tear down replication**. If using High Availability (HA), run `ghe-repl-teardown` on the target instance. Stopping replication with `ghe-repl-stop` is not sufficient, because the target remains configured as part of a replication pair and the restore fails. See [AUTOTITLE](/admin/monitoring-and-managing-your-instance/configuring-high-availability/removing-a-high-availability-replica).
-1. **Prepare for {% data variables.product.prodname_actions %}** — if enabled, ensure the target instance is configured with the correct external storage. See [AUTOTITLE](/admin/backing-up-and-restoring-your-instance/restoring-with-github-actions-enabled) for details.
+1. **Prepare for {% data variables.product.prodname_actions %}**: if enabled, ensure the target instance is configured with the correct external storage. See [AUTOTITLE](/admin/backing-up-and-restoring-your-instance/restoring-with-github-actions-enabled) for details.
+1. **Enable maintenance mode** on the target instance. See [AUTOTITLE](/admin/administering-your-instance/configuring-maintenance-mode/enabling-and-scheduling-maintenance-mode).
+1. **Verify access** to the backup storage containing the snapshot after attaching and mounting the backup disk volume to the target instance. See [AUTOTITLE](/admin/backing-up-and-restoring-your-instance/configuring-the-backup-service#reusing-a-previously-initialized-disk).
 
 ## Starting the restore operation
 
 To restore from a snapshot:
 
 1. SSH into the target instance as the `admin` user.
 1. Run one of the following commands:
-
    * Restore the latest snapshot:
 
      ```shell
@@ -57,19 +57,17 @@ To restore from a snapshot:
    * (Optional) Overwrite appliance configuration, certificates, and license data from the backup. The `-c` option does not control database or repository restoration:
 
      ```shell
-     ghe-restore -c          # Latest snapshot
-     ghe-restore -s <SNAPSHOT_TIMESTAMP> -c  # Specific snapshot
+     ghe-restore -c # Latest snapshot
+     ghe-restore -s <SNAPSHOT_TIMESTAMP> -c # Specific snapshot
      ```
 
 1. **Finalize in {% data variables.enterprise.management_console %}:**
-
     * Review all configuration settings (network, auth, TLS, etc.).
     * Click **Save settings** to apply them and start services.
     * The instance is not fully operational until this step is complete.
-
 1. **Validate the restored instance** to ensure everything works as expected.
+   * (Optional) Configure an IP exception list on the restored instance to allow access to a specified list of IP addresses. For more information, see [AUTOTITLE](/admin/administering-your-instance/configuring-maintenance-mode/enabling-and-scheduling-maintenance-mode#validating-changes-in-maintenance-mode-using-the-ip-exception-list).
 1. **If using HA**, complete the restore on a standalone instance first. Then reconfigure HA.
-
    * If you run into sync issues (e.g., stale UUIDs in `ghe-repl-status`), run `ghe-repl-teardown`.
    * For help, contact {% data variables.contact.github_support %}.
 

content/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository.md

@@ -149,7 +149,10 @@ After using `git-filter-repo` to remove the sensitive data and pushing your chan
     {% ifversion fpt or ghec %}If you have successfully cleaned up all references other than PRs, and no forks have references to the sensitive data, Support will then:{% endif %}
     {% ifversion ghes %}If you have successfully cleaned up all references other than PRs, and no forks have references to the sensitive data, your site administrator will then:{% endif %}
 
-    * Dereference or delete any affected PRs on {% data variables.product.github %}.
+    * Dereference or delete any affected pull requests on {% data variables.product.github %}. Deleting an entire pull request removes its conversation, reviews, and diffs.
+
+      {% ifversion fpt or ghec %}{% data variables.contact.github_support %} may offer to remove only a pull request's internal references ("dereferencing"). This can preserve the pull request body and comment history while making affected historical diffs inaccessible. Dereferencing does not remove sensitive data quoted in retained bodies or comments.{% endif %}
+
     * Run a garbage collection on the server to expunge the sensitive data from storage.
     * Remove cached views.
     * If LFS Objects are involved, delete and/or purge the orphaned LFS objects.

content/billing/concepts/azure-subscriptions.md

@@ -16,6 +16,10 @@ category:
 
 You can pay for {% data variables.product.github %} use through an Azure subscription by connecting the subscription to {% data variables.product.github %}. See [AUTOTITLE](/billing/how-tos/set-up-payment/connect-azure-sub).
 
+If you pay for {% data variables.product.prodname_copilot %} with a credit card or PayPal, you cannot switch your payment method to an Azure subscription. Newly created enterprise accounts paying through Azure must contact {% data variables.contact.github_support %} to enable {% data variables.product.prodname_copilot_short %}.
+
+If your existing {% data variables.product.prodname_enterprise %} subscription is invoiced and volume-based, connecting an Azure subscription routes metered usage to Azure but does not move existing license charges. To have these charges billed through Azure, work with your account manager to transition your enterprise to fully metered billing. Ask your account manager to confirm when the transition can take effect relative to your renewal and how it will affect your billing.
+
 {% data variables.product.github %} installs a Subscription Permission Validation app (SPV app) on the Azure tenant, which it uses to get a list of available subscriptions from active directory. Installing the SPV app requires tenant-wide admin consent. You must sign into an Azure account that can provide tenant-wide admin consent, or work with an Azure administrator to configure the admin consent workflow.
 
 * [Grant tenant-wide admin consent to an application](https://learn.microsoft.com/azure/active-directory/manage-apps/grant-admin-consent) in Microsoft Docs

content/copilot/concepts/models/bring-your-own-key.md

@@ -45,3 +45,12 @@ Custom models are available in {% data variables.copilot.copilot_byok_supported_
 Users access these models through {% data variables.product.github %}'s {% data variables.product.prodname_copilot_short %} API without configuring the provider's credentials themselves. Users must have a {% data variables.product.prodname_copilot_short %} license and internet access to use the custom models.
 
 For more information, see [AUTOTITLE](/copilot/how-tos/administer-copilot/manage-for-enterprise/enable-custom-models).
+
+## Choosing between the two
+
+For most organizations, we recommend enterprise custom models as the default, with BYOK configured by users allowed where it's needed.
+
+* **Enterprise custom models** keep provider keys under central control, so users never handle credentials. Requests are routed through {% data variables.product.github %}, so usage is fully reported in {% data variables.product.prodname_copilot_short %} usage metrics.
+* **BYOK configured by users** fits local or on-device models, air-gapped environments, and experimentation with new providers. Its usage is reported from client telemetry in supported clients only. You can disable it in IDEs with a policy.
+
+To see how each kind is used, see [AUTOTITLE](/copilot/reference/copilot-usage-metrics/copilot-usage-metrics#byok-metrics-fields).