Merge branch 'main' into main

Author: Sharra-writes

.github/actions/labeler/labeler.ts

@@ -1,6 +1,6 @@
 /* See function main in this file for documentation */
 
-import coreLib from '@actions/core'
+import * as coreLib from '@actions/core'
 import { type Octokit } from '@octokit/rest'
 import { CoreInject } from '@/links/scripts/action-injections'
 

.github/instructions/all.instructions.md

@@ -12,9 +12,9 @@ When you create a pull request:
 
 1. **Always** make the first line of the PR description the following (in italics):
 
-   `_Copilot Chat generated this pull request._`
+   `_GitHub Copilot generated this pull request._`
 
-2. Optionally, you may include a collapsed section summarizing the prompt or discussion with Copilot Chat:
+2. Optionally, you may include a collapsed section summarizing the prompt or discussion with Copilot:
 
    ```markdown
    <details><summary>Prompt summary - submitted by @GITHUB-USER-ID</summary>
@@ -29,4 +29,4 @@ When you create a pull request:
 3. Label with "llm-generated". 
 4. If an issue exists, include "fixes owner/repo#issue" or "towards owner/repo#issue" as appropriate. 
 5. Always create PRs in **draft mode** using `--draft` flag.
-6. Always _escape backticks_ when you use gh cli.
+6. When you are using gh cli, always _escape backticks_.

.github/instructions/code.instructions.md

@@ -9,10 +9,10 @@ For code reviews, follow guidelines, tests, and validate instructions. For creat
 ## Guidelines
 
 - If available, use ripgrep (`rg`) instead of `grep`.
-- Make sure to always _escape backticks_ when using gh cli.
+- When using gh cli, always _escape backticks_.
 - All scripts should be listed in `package.json` and use `tsx`.
-- Whenever you create or comment on an issue or pull request, indicate you are an LLM.
-- Be careful fetching full HTML pages off the internet. Prefer to use gh cli whenever possible for github.com. Limit the number of tokens when grabbing HTML.
+- Whenever you create or comment on an issue or pull request, indicate you are GitHub Copilot.
+- Be careful fetching full HTML pages off the internet. Prefer to use MCP or gh cli whenever possible for github.com. Limit the number of tokens when grabbing HTML.
 - Avoid pull requests with over 300 lines of code changed. When significantly larger, offer to split up into smaller pull requests if possible.
 - All new code should be written in TypeScript and not JavaScript.
 - We use absolute imports, relative to the `src` directory, using the `@` symbol. For example, `getRedirect` which lives in `src/redirects/lib/get-redirect.ts` can be imported with `import getRedirect from '@/redirects/lib/get-redirect'`. The same rule applies for TypeScript (`.ts`) imports, e.g. `import type { GeneralSearchHit } from '@/search/types'`
@@ -43,7 +43,7 @@ Run the following commands to validate your changes:
 
 0. Ask the human if they would like you to follow these steps.
 1. If this is new work, make sure you have the latest changes by running `git checkout main && git pull`. If this is existing work, update the branch you are working on with the head branch -- usually `main`.
-2. If the human provides a GitHub issue, use gh cli to read the issue and all comments.
+2. If the human provides a GitHub issue, use MCP or gh cli to read the issue and all comments.
 3. Begin by evaluating impact, effort, and estimate non-test lines of code that will change. Ask for more context and examples if needed.
 4. If you are running in agentic mode, _stop_ at this point and request approval from the human.
 5. If you need to add or change tests, work on tests before implementing.
@@ -52,7 +52,7 @@ Run the following commands to validate your changes:
 8. Validate that any new or changed tests pass. See "Tests".
 9. Validate that these changes meet our guidelines. See "Guidelines".
 10. If you are running in agentic mode, _stop_ at this point and request review before continuing. Suggest how the human should review the changes.
-11. If a branch and pull request already exist, commit and push, then _concisely_ comment on the pull request that you are an LLM and what changes you made and why. 
+11. If a branch and pull request already exist, commit and push, then _concisely_ comment on the pull request that you are GitHub Copilot and what changes you made and why. 
 12. If this is new work and no pull request exists yet, make a pull request:
     - label "llm-generated"
     - draft mode
@@ -61,4 +61,4 @@ Run the following commands to validate your changes:
 14. If you are in agentic mode, offer to do any or all of:
     - mark the pull request as ready,
     - assign the issue to the human if it is not already assigned, 
-    - _concisely_ comment on the issue explaining the change, indicating you are an LLM.
+    - _concisely_ comment on the issue explaining the change, indicating you are GitHub Copilot.

.github/workflows/check-broken-links-github-github.yml

@@ -44,10 +44,9 @@ jobs:
           PORT: 4000
           ENABLED_LANGUAGES: en
         run: |
-
-          npm run start &
+          npm run start-for-ci &
           sleep 5
-          curl --retry-connrefused --retry 3 -I http://localhost:4000/
+          curl --retry-connrefused --retry 5 -I http://localhost:4000/
 
       - name: Run broken github/github link check
         run: |

.github/workflows/index-general-search.yml

@@ -230,21 +230,64 @@ jobs:
           FASTLY_SURROGATE_KEY: api-search:${{ matrix.language }}
         run: npm run purge-fastly-edge-cache
 
-      - name: Alert on scraping failures
-        if: ${{ steps.check-failures.outputs.has_failures == 'true' && github.event_name != 'workflow_dispatch' }}
-        uses: ./.github/actions/slack-alert
+      - name: Upload failures artifact
+        if: ${{ steps.check-failures.outputs.has_failures == 'true' }}
+        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
+        with:
+          name: search-failures-${{ matrix.language }}
+          path: /tmp/records/failures-summary.json
+          retention-days: 1
+
+      - uses: ./.github/actions/slack-alert
+        if: ${{ failure() && github.event_name != 'workflow_dispatch' }}
         with:
           slack_channel_id: ${{ secrets.DOCS_ALERTS_SLACK_CHANNEL_ID }}
           slack_token: ${{ secrets.SLACK_DOCS_BOT_TOKEN }}
-          message: |
-            :warning: ${{ steps.check-failures.outputs.failed_pages }} page(s) failed to scrape for general search indexing (language: ${{ matrix.language }})
 
-            The indexing completed but some pages could not be scraped. This may affect search results for those pages.
+  notifyScrapingFailures:
+    name: Notify scraping failures
+    needs: updateElasticsearchIndexes
+    if: ${{ always() && github.repository == 'github/docs-internal' && github.event_name != 'workflow_dispatch' && needs.updateElasticsearchIndexes.result != 'cancelled' }}
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out repo
+        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
+
+      - name: Download all failure artifacts
+        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+        with:
+          pattern: search-failures-*
+          path: /tmp/failures
+        continue-on-error: true
 
-            Workflow: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
+      - name: Check if any failures were downloaded
+        id: check-artifacts
+        run: |
+          if [ -d /tmp/failures ] && [ "$(ls -A /tmp/failures 2>/dev/null)" ]; then
+            echo "has_artifacts=true" >> $GITHUB_OUTPUT
+          else
+            echo "has_artifacts=false" >> $GITHUB_OUTPUT
+          fi
 
-      - uses: ./.github/actions/slack-alert
-        if: ${{ failure() && github.event_name != 'workflow_dispatch' }}
+      - uses: ./.github/actions/node-npm-setup
+        if: ${{ steps.check-artifacts.outputs.has_artifacts == 'true' }}
+
+      - name: Aggregate failures and format message
+        if: ${{ steps.check-artifacts.outputs.has_artifacts == 'true' }}
+        id: aggregate
+        run: |
+          RESULT=$(npx tsx src/search/scripts/aggregate-search-index-failures.ts /tmp/failures \
+            --workflow-url "${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}")
+          {
+            echo 'result<<EOF'
+            echo "$RESULT"
+            echo 'EOF'
+          } >> "$GITHUB_OUTPUT"
+
+      - name: Send consolidated Slack notification
+        if: ${{ steps.check-artifacts.outputs.has_artifacts == 'true' }}
+        uses: ./.github/actions/slack-alert
         with:
           slack_channel_id: ${{ secrets.DOCS_ALERTS_SLACK_CHANNEL_ID }}
           slack_token: ${{ secrets.SLACK_DOCS_BOT_TOKEN }}
+          message: ${{ fromJSON(steps.aggregate.outputs.result).message }}

LICENSE-CODE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright 2025 GitHub
+Copyright 2026 GitHub
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

assets/images/help/teams/list-of-members-selected-bulk.png

@@ -115,6 +115,20 @@ For more information, see [AUTOTITLE](/actions/reference/openid-connect-referenc
 
 {% data variables.product.prodname_actions %} workflows can use OIDC tokens instead of secrets to authenticate with cloud providers. Many popular cloud providers offer official login actions that simplify the process of using OIDC in your workflows. For more information about updating your workflows with specific cloud providers, see [AUTOTITLE](/actions/how-tos/security-for-github-actions/security-hardening-your-deployments).
 
+## OIDC support for {% data variables.product.prodname_dependabot %}
+
+{% data variables.product.prodname_dependabot %} can use OIDC to authenticate with private registries, eliminating the need to store long-lived credentials as repository secrets. With OIDC-based authentication, {% data variables.product.prodname_dependabot %} update jobs can dynamically obtain short-lived credentials from your cloud identity provider.
+
+{% data variables.product.prodname_dependabot %} supports OIDC authentication for any registry type that uses `username` and `password` authentication, when the registry is hosted on AWS CodeArtifact, Azure DevOps Artifacts, or JFrog Artifactory.
+
+The benefits of OIDC authentication for {% data variables.product.prodname_dependabot %} are:
+
+* **Enhanced security:** Eliminates static, long-lived credentials from your repositories.
+* **Simpler management:** Enables secure, policy-compliant access to private registries.
+* **Avoid rate limiting:** Dynamic credentials help you avoid hitting rate limits associated with static tokens.
+
+For more information, see [AUTOTITLE](/code-security/dependabot/working-with-dependabot/configuring-access-to-private-registries-for-dependabot#using-oidc-for-authentication).
+
 ## Next steps
 
 For more information about configuring OIDC, see [AUTOTITLE](/actions/how-tos/security-for-github-actions/security-hardening-your-deployments).

content/actions/concepts/security/openid-connect.md

@@ -37,7 +37,7 @@ Some information that {% data variables.contact.github_support %} will request c
 * A copy of your workflow run logs for an example workflow run failure. For more information about workflow run logs, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#downloading-logs).
 * {% ifversion ghes %}A copy of your runner logs, {% else %}If you are running this workflow on a self-hosted runner, self-hosted runner logs{% endif %} which can be found under the `_diag` folder within the runner. For more information about self-hosted runners, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners#reviewing-the-self-hosted-runner-application-log-files).
 
-  Self-hosted runner log file names are be formatted: `Runner_YYYY####-xxxxxx-utc.log` and `Worker_YYYY####-xxxxxx-utc.log`.
+  Self-hosted runner log file names are formatted: `Runner_YYYY####-xxxxxx-utc.log` and `Worker_YYYY####-xxxxxx-utc.log`.
 
 > [!NOTE]
 > Attach files to your support ticket by changing the file's extension to `.txt` or `.zip`. If you include textual data such as log or workflow file snippets inline in your ticket, ensure they are formatted correctly as Markdown code blocks. For more information about proper Markdown formatting, see [AUTOTITLE](/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#quoting-code).

content/actions/how-tos/get-support.md

@@ -70,20 +70,34 @@ When routing a job to a self-hosted runner, {% data variables.product.prodname_d
 
 ## Autoscaling
 
-You can automatically increase or decrease the number of self-hosted runners in your environment in response to the webhook events you receive with a particular label.
+Autoscaling allows you to dynamically adjust the number of self-hosted runners based on demand. This helps optimize resource utilization and ensures sufficient runner capacity during peak times while reducing costs during periods of low activity. There are multiple approaches to implementing autoscaling for self-hosted runners, each with different trade-offs in terms of complexity, reliability, and responsiveness.
 
-### Supported autoscaling solutions
+### {% data variables.product.prodname_actions_runner_controller %}
 
 {% ifversion fpt or ghec %}
 
-{% data variables.product.prodname_dotcom %}-hosted runners inherently autoscale based on your needs. {% data variables.product.prodname_dotcom %}-hosted runners can be a low-maintenance and cost-effective alternative to developing or implementing autoscaling solutions. For more information, see [AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners).
+{% data variables.product.github %}-hosted runners inherently autoscale based on your needs. {% data variables.product.github %}-hosted runners can be a low-maintenance and cost-effective alternative to developing or implementing autoscaling solutions. For more information, see [AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners).
 
 {% endif %}
 
-The [actions/actions-runner-controller](https://github.com/actions/actions-runner-controller) (ARC) project is a Kubernetes-based runner autoscaler. {% data variables.product.prodname_dotcom %} recommends ARC if the team deploying it has expert Kubernetes knowledge and experience.
+{% data variables.product.prodname_actions_runner_controller %} (ARC) is the reference implementation of {% data variables.product.github %}'s scale set APIs and the recommended Kubernetes-based solution for autoscaling self-hosted runners. ARC provides a complete, production-ready autoscaling solution for teams running {% data variables.product.prodname_actions %} in Kubernetes environments.
+
+{% data variables.product.github %} recommends ARC for organizations with Kubernetes infrastructure and teams that have Kubernetes expertise. ARC handles the full lifecycle of runners within your cluster, from provisioning to job execution to cleanup.
 
 For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-actions-runner-controller) and [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-support-for-actions-runner-controller).
 
+### {% data variables.product.prodname_actions %} Runner Scale Set Client 
+
+The {% data variables.product.prodname_actions %} Runner Scale Set Client is a standalone Go-based module that empowers platform teams, integrators, and infrastructure providers to build custom autoscaling solutions for {% data variables.product.prodname_actions %} runners across VMs, containers, on-premise infrastructure, and cloud services, with support for Windows, Linux, and macOS platforms.
+
+The client orchestrates {% data variables.product.github %} API interactions for scale sets while leaving infrastructure provisioning to you. You define how runners are created, scaled, and destroyed, and configure runners with multiple labels for flexible job routing and targeting. This gives organizations granular control over runner lifecycle management and real-time telemetry for job execution.
+
+The client is designed to work out of the box with basic configurations, allowing teams to quickly implement autoscaling. However, its true power lies in its flexibility—the client is built to be extended and customized to meet each organization's specific infrastructure requirements, compliance constraints, and operational workflows. Whether you need simple scaling logic or complex, multi-environment provisioning strategies, the client adapts to your needs.
+
+The {% data variables.product.prodname_actions %} Runner Scale Set Client is an open source project. The [actions/scaleset repository](https://github.com/actions/scaleset) contains the complete source code, comprehensive documentation, and practical examples to help you get started. You'll find implementation guides, sample configurations for various infrastructure scenarios, and reference architectures demonstrating how to integrate the client with different provisioning systems. The repository also includes contributing guidelines for teams interested in extending the client or sharing their autoscaling patterns with the community.
+
+> **Note:** The Runner Scale Set Client is not a replacement for {% data variables.product.prodname_actions_runner_controller %} (ARC), which remains the reference implementation of the scale set APIs and the recommended Kubernetes solution for autoscaling runners. Instead, the client is a complementary tool for interfacing with the same scale set APIs to build custom autoscaling solutions outside of Kubernetes.
+
 ### Ephemeral runners for autoscaling
 
 {% data variables.product.prodname_dotcom %} recommends implementing autoscaling with ephemeral self-hosted runners; autoscaling with persistent self-hosted runners is not recommended. In certain cases, {% data variables.product.prodname_dotcom %} cannot guarantee that jobs are not assigned to persistent runners while they are shut down. With ephemeral runners, this can be guaranteed because {% data variables.product.prodname_dotcom %} only assigns one job to a runner.
@@ -130,6 +144,8 @@ You can create your own autoscaling environment by using payloads received from
 * For more information about the `workflow_job` webhook, see [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_job).
 * To learn how to work with webhooks, see [AUTOTITLE](/webhooks).
 
+> **Note:** This approach relies on the timeliness of webhook delivery for making scaling decisions, which can introduce delays and reliability concerns. Consider using Actions Controller or the Scale Set Client for larger volume autoscaling scenarios.
+
 ### Authentication requirements
 
 You can register and delete repository and organization self-hosted runners using [the API](/rest/actions/self-hosted-runners). To authenticate to the API, your autoscaling implementation can use an access token or a {% data variables.product.prodname_dotcom %} app.