Repo sync

.github/workflows/enterprise-dates.yml

@@ -32,7 +32,7 @@ jobs:
           app-id: ${{ secrets.DOCS_BOT_APP_ID }}
           private-key: ${{ secrets.DOCS_BOT_APP_PRIVATE_KEY }}
           owner: github
-          repositories: docs-internal,docs-engineering
+          repositories: docs-internal,docs-engineering,enterprise-releases
 
       - uses: ./.github/actions/node-npm-setup
 

.github/workflows/enterprise-release-issue.yml

@@ -27,7 +27,7 @@ jobs:
           app-id: ${{ secrets.DOCS_BOT_APP_ID }}
           private-key: ${{ secrets.DOCS_BOT_APP_PRIVATE_KEY }}
           owner: github
-          repositories: docs-content,docs-engineering
+          repositories: docs-content,docs-engineering,enterprise-releases
 
       - uses: ./.github/actions/node-npm-setup
 

.github/workflows/link-check-external.yml

@@ -61,15 +61,6 @@ jobs:
         run: |
           if [ -f "artifacts/external-link-report.md" ]; then
             echo "has_report=true" >> $GITHUB_OUTPUT
-            # Prepend disclaimer banner
-            tmp=$(mktemp)
-            {
-              echo "> [!NOTE]"
-              echo "> **No action needed right now.** The link checker is being actively worked on and may produce false positives. You can safely ignore this report for now. We'll let you know when it's reliable."
-              echo ""
-              cat "artifacts/external-link-report.md"
-            } > "$tmp"
-            mv "$tmp" "artifacts/external-link-report.md"
           else
             echo "has_report=false" >> $GITHUB_OUTPUT
             echo "No broken link report generated - all links valid!"

.github/workflows/link-check-github-github.yml

@@ -55,6 +55,9 @@ jobs:
           curl --retry-connrefused --retry 5 -I http://localhost:4000/
 
       - name: Run broken github/github link check
+        env:
+          # Needs a token with access to github/github; the app token is scoped to it above
+          GITHUB_TOKEN: ${{ steps.app-token.outputs.token }}
         run: |
           npm run check-github-github-links -- broken_github_github_links.md
 

.github/workflows/link-check-internal.yml

@@ -248,9 +248,6 @@ jobs:
             # Combine all markdown reports
             echo "# Internal Links Report" > combined-report.md
             echo "" >> combined-report.md
-            echo "> [!NOTE]" >> combined-report.md
-            echo "> **No action needed right now.** The link checker is being actively worked on and may produce false positives. You can safely ignore this report for now. We'll let you know when it's reliable." >> combined-report.md
-            echo "" >> combined-report.md
             echo "Generated: $(date -u +'%Y-%m-%d %H:%M UTC')" >> combined-report.md
             echo "[Action run](${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }})" >> combined-report.md
             echo "" >> combined-report.md

.github/workflows/link-check-on-pr.yml

@@ -8,7 +8,7 @@ on:
   workflow_dispatch:
   # merge_group:
   pull_request:
-    types: [labeled, opened, synchronize, reopened]
+    types: [opened, synchronize, reopened]
 
 permissions:
   contents: read
@@ -24,9 +24,7 @@ jobs:
   check-links:
     name: Check links
     runs-on: ubuntu-latest
-    if: |
-      (github.repository == 'github/docs-internal' || github.repository == 'github/docs') &&
-      (github.event_name == 'workflow_dispatch' || contains(github.event.pull_request.labels.*.name, 'check-links'))
+    if: github.repository == 'github/docs-internal' || github.repository == 'github/docs'
     steps:
       - name: Checkout
         uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
@@ -61,12 +59,14 @@ jobs:
 
       - name: Check links in changed files
         if: steps.changed-files.outputs.any_changed == 'true'
+        # Work in progress: never fail the PR. The comment is informational only.
+        continue-on-error: true
         env:
           FILES_CHANGED: ${{ steps.changed-files.outputs.all_changed_files }}
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           ACTION_RUN_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
           SHOULD_COMMENT: ${{ secrets.DOCS_BOT_APP_ID != '' }}
-          FAIL_ON_FLAW: true
+          FAIL_ON_FLAW: false
           ENABLED_LANGUAGES: en
         run: npm run check-links-pr
 

content/actions/reference/workflows-and-actions/workflow-syntax.md

@@ -915,6 +915,9 @@ Outputs and environment changes from a background step are only available after
 
 Use `background` when you need fine-grained control: starting a long-running process (like a server or database) that stays up while later steps run, referencing a specific step with [`wait`](#jobsjob_idstepswait) or [`cancel`](#jobsjob_idstepscancel), or interleaving background work with other steps. If you instead have a self-contained group of steps that should all finish before the job continues, [`parallel`](#jobsjob_idstepsparallel) is a more convenient shorthand.
 
+> [!NOTE]
+> You cannot use `background` on steps inside a composite action. A composite action can itself run as a background step, but it cannot declare background steps internally.
+
 ### Example: Running a step in the background
 
 ```yaml
@@ -937,6 +940,9 @@ Pauses the job until one or more background steps complete. A `wait` step perfor
 
 After a `wait` step completes, the outputs of the referenced background steps become available to subsequent steps. If a referenced background step failed, the `wait` step fails too.
 
+> [!NOTE]
+> A `wait` step always runs and does not support the [`if`](#jobsjob_idstepsif) conditional.
+
 ### Example: Waiting for specific background steps
 
 ```yaml
@@ -967,6 +973,9 @@ Pauses the job until all active background steps complete. This is useful when s
 
 The `wait-all` keyword takes no arguments.
 
+> [!NOTE]
+> A `wait-all` step always runs and does not support the [`if`](#jobsjob_idstepsif) conditional.
+
 ### Example: Waiting for all background steps
 
 ```yaml
@@ -992,6 +1001,9 @@ steps:
 
 Gracefully terminates a running background step. The runner sends the step's process a termination signal (`SIGTERM`) so it can clean up, and forcibly stops it (`SIGKILL`) if it does not exit within a short grace period. The `cancel` keyword targets a single background step by its `id`.
 
+> [!NOTE]
+> A `cancel` step always runs and does not support the [`if`](#jobsjob_idstepsif) conditional.
+
 ### Example: Canceling a background step
 
 ```yaml
@@ -1016,6 +1028,9 @@ Use `parallel` when you have a self-contained group of steps that should all fin
 
 Each step in the group is subject to the same 10-step concurrency limit as other background steps.
 
+> [!NOTE]
+> You cannot use `parallel` inside a composite action.
+
 ### Example: Running steps in parallel
 
 ```yaml

content/copilot/reference/ai-models/model-hosting.md

@@ -50,6 +50,7 @@ Used for:
 * {% data variables.copilot.copilot_claude_haiku_45 %}
 * {% data variables.copilot.copilot_claude_sonnet_45 %}
 * {% data variables.copilot.copilot_claude_sonnet_46 %}
+* {% data variables.copilot.copilot_claude_sonnet_5 %}
 * {% data variables.copilot.copilot_claude_opus_45 %}
 * {% data variables.copilot.copilot_claude_opus_46 %}
 * {% data variables.copilot.copilot_claude_opus_47 %}

content/copilot/reference/ai-models/supported-models.md

@@ -83,6 +83,7 @@ Choosing a larger context window or higher reasoning will impact {% data variabl
 | {% data variables.copilot.copilot_claude_opus_46 %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} |
 | {% data variables.copilot.copilot_claude_opus_47 %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} |
 | {% data variables.copilot.copilot_claude_opus_48 %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} |
+| {% data variables.copilot.copilot_claude_sonnet_5 %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} |
 | {% data variables.copilot.copilot_claude_opus_48_fast %} | {% octicon "x" aria-label="Not supported" %} | {% octicon "check" aria-label="Supported" %} |
 | {% data variables.copilot.copilot_claude_fable_5 %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} |
 | {% data variables.copilot.copilot_gpt_53_codex %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} |
@@ -141,8 +142,9 @@ Some {% data variables.product.prodname_copilot_short %} models require minimum
 | {% data variables.copilot.copilot_gpt_54_mini %}         | `v1.104.1` and later | `17.14.19` and later                     | `1.5.66` and later | `0.47.0` and later | `0.15.0` and later |
 | {% data variables.copilot.copilot_gpt_55 %}              | `v1.117` and later   | `17.14.19` and later                     | `1.5.66` and later | `0.47.0` and later | `0.15.0` and later |
 | {% data variables.copilot.copilot_claude_opus_48 %}      | `v1.118` and later   | `17.14.6` and later                     | TBD | TBD | TBD |
+| {% data variables.copilot.copilot_claude_sonnet_5 %}  | `v1.124` and later | `17.14.6` and later | TBD | TBD | TBD |
 | {% data variables.copilot.copilot_claude_fable_5 %}      | `v1.124` and later   | `17.14.6` and later                    | TBD | TBD | TBD |
-| {% data variables.copilot.copilot_mai_code_1_flash %}    | `v1.121` and later   | Not available                            | Not available | Not available | Not available |
+| {% data variables.copilot.copilot_mai_code_1_flash %}    | `v1.121` and later   | TBD                            | TBD | TBD | TBD |
 
 {% endrowheaders %}
 

content/copilot/reference/copilot-billing/models-and-pricing.md

@@ -97,3 +97,5 @@ You can view your current {% data variables.product.prodname_actions %} usage fo
 ## Model multipliers for annual {% data variables.copilot.copilot_pro_short %} and {% data variables.copilot.copilot_pro_plus_short %} subscribers
 
 {% data variables.copilot.copilot_pro_short %} and {% data variables.copilot.copilot_pro_plus_short %} subscribers on **existing annual billing plans** using the **request-based billing** model have different model multipliers. See [AUTOTITLE](/copilot/reference/copilot-billing/model-multipliers-for-annual-plans).
+
+[^sonnet-5-promo]: {% data variables.copilot.copilot_claude_sonnet_5 %} is available at the promotional pricing of $2.00 per 1M input tokens, $0.20 per 1M cached input tokens, $2.50 per 1M cache write tokens, and $10.00 per 1M output tokens through August 31, 2026. 

content/copilot/reference/copilot-usage-metrics/copilot-usage-metrics.md

@@ -67,7 +67,7 @@ These fields appear in the exported NDJSON reports and in the {% data variables.
 
 Reports come in different shapes depending on their scope and granularity, so the fields available in a record depend on which report it comes from:
 
-* **Per-user reports** (`*-users-1-day` and `*-users-28-day`) contain one record per user, including `user_id`, `user_login`, the `used_*` indicators, and `ai_adoption_phase`. They do not contain active-user counts, `pull_requests`, or `totals_by_ai_adoption_phase`.
+* **Per-user reports** (`*-users-1-day` and `*-users-28-day`) contain one record per user, including `user_id`, `user_login`, `ai_credits_used`, the `used_*` indicators, and `ai_adoption_phase`. They do not contain active-user counts, `pull_requests`, or `totals_by_ai_adoption_phase`.
 * **Aggregated reports** (`enterprise-1-day` and `org-1-day`) contain one aggregated record per enterprise or organization, including active-user counts, `pull_requests`, and `totals_by_ai_adoption_phase`. They do not contain `user_id`, `user_login`, or the `used_*` indicators.
 * **28-day reports** (`enterprise-28-day` and `org-28-day`) wrap an array of daily aggregated records in a `day_totals` field, with the reporting window at the top level.
 * **User-teams reports** (`*-user-teams-1-day`) map users to the teams they belong to, so you can construct team-level metrics.
@@ -96,6 +96,7 @@ Per-user reports contain one record per user for the reporting period. The 28-da
 |:--|:--|:--|:--|
 | `user_id` | `integer` | No | Unique identifier for the user. |
 | `user_login` | `string` | No | {% data variables.product.github %} username for the user. |
+| `ai_credits_used` | `number` | No | Total AI credits consumed by the user in the reporting period. This field is included in per-user reports only and is not broken down by feature, model, or surface. This metric is for consumption analysis, not invoicing totals. |
 | `user_initiated_interaction_count` | `integer` | No | Number of explicit prompts sent to {% data variables.product.prodname_copilot_short %}.<br><br>Only counts messages or prompts actively sent to the model. Does **not** include opening the chat panel, switching modes (for example, ask, edit, plan, or agent), using keyboard shortcuts to open the inline UI, or making configuration changes. |
 | `code_generation_activity_count` | `integer` | No | Number of distinct {% data variables.product.prodname_copilot_short %} output events generated. <br><br> **Includes:** All generated content, including comments and docstrings. <br> **Multiple blocks:** Each distinct code block from a single user prompt counts as a separate generation. <br> **Note:** This metric is not directly comparable to `user_initiated_interaction_count`, since one prompt can produce multiple generations. |
 | `code_acceptance_activity_count` | `integer` | No | Number of suggestions or code blocks accepted by users. <br><br> **Counts:** All built-in accept actions, such as “apply to file,” “insert at cursor,” “insert into terminal,” and use of the **Copy** button. <br> **Does not count:** Manual OS clipboard actions (for example, <kbd>Ctrl</kbd>+<kbd>C</kbd>). <br> **Granularity:** Each acceptance action increments the count once, regardless of how many code blocks were generated by the initial prompt. |

content/copilot/reference/copilot-usage-metrics/example-schema.md

@@ -19,6 +19,7 @@ The following are example schemas for the user-level and enterprise-level data r
 
 ```json copy
 [{
+  "ai_credits_used": 12.5,
   "code_acceptance_activity_count": 1,
   "code_generation_activity_count": 1,
   "day": "2025-10-01",

content/migrations/elm/about-live-migrations.md

@@ -7,7 +7,6 @@ versions:
   ghes: '*'
   ghec: '*'
 contentType: concepts
-product: '{% data reusables.elm.ghes-version-requirement %}'
 ---
 
 {% data reusables.elm.preview-note %}
@@ -43,7 +42,7 @@ The high-level phases of a migration are:
 1. **Creation**: The site admin runs CLI commands to create and start the migration, specifying the source repository and destination.
 1. **Preflight checks**: The migration service verifies parameters, tokens, network connectivity, and repository configuration.
 1. **Backfill**: The {% data variables.product.prodname_elm_short %} tool does an initial crawl to capture all repository data and sends it to the migration service on the destination platform. During the backfill phase, webhooks check for live updates to the repository as the migration continues.
-1. **Cutover**: The source repository is locked and any final live updates are sent to {% data variables.product.prodname_elm_short %}. This is the downtime period for developers.
+1. **Cutover**: The source repository is archived (made read-only) and any final live updates are sent to {% data variables.product.prodname_elm_short %}. This is the downtime period for developers.
 1. **Completion**: The migration is finished. The site admin can check the data was migrated successfully.
 1. **Follow-up**: An organization owner performs follow-up tasks on the destination enterprise, such as reconfiguring organization settings and reattributing activity to users.
 

content/migrations/elm/elm-cli-reference.md

@@ -20,7 +20,7 @@ contentType: reference
 | `elm migration status --migration-id MIGRATION-ID` | Shows the status, progress, cutover readiness, and timing of a migration |
 | `elm migration list` | Lists all migrations and their statuses |
 | `elm migration cancel --migration-id MIGRATION-ID` | Cancels a migration in progress |
-| `elm migration cutover-to-destination --migration-id MIGRATION-ID` | Initiates the final cutover, locking the source repository and completing the migration |
+| `elm migration cutover-to-destination --migration-id MIGRATION-ID` | Initiates the final cutover, archiving the source repository and completing the migration |
 
 Some of these commands can take additional options. See the later sections in this article.
 

content/migrations/elm/migrate-your-repository.md

@@ -7,7 +7,6 @@ versions:
   ghes: '*'
   ghec: '*'
 contentType: how-tos
-product: '{% data reusables.elm.ghes-version-requirement %}'
 permissions: 'Site administrators on {% data variables.product.prodname_ghe_server %} who are also enterprise owners on {% data variables.enterprise.data_residency_site %}.'
 ---
 
@@ -60,18 +59,7 @@ You must set some configuration on the {% data variables.product.prodname_ghe_se
    | `secrets.elm-exporter.migration-target-token` | The access token you created for {% data variables.enterprise.data_residency_site %}. |
    | `secrets.elm-exporter.source-token` | The access token you created for {% data variables.product.prodname_ghe_server %}. |
    | `secrets.elm-exporter.source-user` | The username associated with the {% data variables.product.prodname_ghe_server %} token (for example: `ghe-admin`). |
-
-1. If you **don't** already have migrations enabled and blob storage configured on the instance, you can configure them now. You can check your existing settings in in "Migrations" section of the Management Console (`HOSTNAME/setup/settings`).
-
-   You can use the following default values, which will not introduce any unexpected functionality.
-
-   ```shell copy
-   ghe-config app.migrations.enabled true
-   ```
-
-   ```shell copy
-   ghe-config secrets.migrations.blob-storage-type local-storage
-   ```
+   | `app.migrations.enabled` | If you don't already have migrations enabled on the instance, you must set this to `true`. |
 
 1. Apply the configuration.
 
@@ -194,7 +182,7 @@ Tips:
 
 ## 7. Complete the migration
 
-When a migration is ready for cutover, you can complete the migration. The cutover process will lock the source repository, making it **permanently unavailable** for developers unless an administrator unlocks it.
+When a migration is ready for cutover, you can complete the migration. The cutover process will archive the source repository, making it **permanently read-only** unless a repository administrator unarchives it.
 
 ``` shell copy
 elm migration cutover-to-destination --migration-id $MIGRATION_ID