Merge branch 'main' into main

Author: DisabledAbel

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

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

@@ -43,6 +43,8 @@ The standard {% data variables.product.prodname_codeql %} packs for all supporte
   * `codeql/ruby-queries`
   * `codeql/swift-queries`
 
+For more information about compatibility between published query packs and different {% data variables.product.prodname_codeql %} releases, see [AUTOTITLE](/code-security/codeql-cli/using-the-advanced-functionality-of-the-codeql-cli/publishing-and-using-codeql-packs#about-codeql-pack-compatibility).
+
 You can also use the {% data variables.product.prodname_codeql_cli %} to create your own {% data variables.product.prodname_codeql %} packs, add dependencies to packs, and install or update dependencies.
 
 You can publish {% data variables.product.prodname_codeql %} packs that you have created, using the {% data variables.product.prodname_codeql_cli %}. For more information on publishing and downloading {% data variables.product.prodname_codeql %} packs, see [AUTOTITLE](/code-security/codeql-cli/using-the-advanced-functionality-of-the-codeql-cli/publishing-and-using-codeql-packs).

content/code-security/concepts/code-scanning/codeql/codeql-query-packs.md

@@ -17,5 +17,6 @@ children:
   - /about-code-scanning-alerts
   - /setup-types
   - /about-integration-with-code-scanning
+  - /sarif-files
   - /codeql
 ---

content/code-security/concepts/code-scanning/index.md

@@ -0,0 +1,31 @@
+---
+title: About SARIF files for code scanning
+shortTitle: SARIF files
+intro: SARIF files convert third-party analyses into alerts on {% data variables.product.github %}.
+topics:
+  - Code Security
+  - Code scanning
+versions:
+  fpt: '*'
+  ghes: '*'
+  ghec: '*'
+contentType: concepts
+---
+
+>[!NOTE] If you use default setup for {% data variables.product.prodname_code_scanning %}, or an advanced setup that involves using {% data variables.product.prodname_actions %} to run the {% data variables.product.prodname_codeql %} action, then you don't need to interact with SARIF files. Scan results are uploaded and parsed as {% data variables.product.prodname_code_scanning %} alerts automatically.
+
+SARIF stands for _Static Analysis Results Interchange Format_. This is a JSON-based standard for storing results from static analysis tools.
+
+If you use a **third-party analysis tool or CI/CD system** to scan code for vulnerabilities, you can generate a SARIF file and upload it to {% data variables.product.github %}. {% data variables.product.github %} will parse the SARIF file and show alerts using the results in your repository as a part of the {% data variables.product.prodname_code_scanning %} experience.
+
+{% data variables.product.github %} uses properties in the SARIF file to display alerts. For example, the `shortDescription` and `fullDescription` appear at the top of a {% data variables.product.prodname_code_scanning %} alert. The `location` allows {% data variables.product.github %} to show annotations in your code file.
+
+This article explains how SARIF files are used on {% data variables.product.github %}. If you're new to SARIF and want to learn more, see Microsoft's [`SARIF tutorials`](https://github.com/microsoft/sarif-tutorials) repository.
+
+## Version requirements
+
+{% data variables.product.prodname_code_scanning_caps %} supports a subset of the [SARIF 2.1.0](https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html) JSON schema. Ensure that SARIF files from third-party tools use this version.
+
+## Upload methods
+
+You can upload a SARIF file using {% data variables.product.prodname_actions %}, the {% data variables.product.prodname_code_scanning %} API, or the {% data variables.product.prodname_codeql_cli %}. The best upload method depends on how you generate the SARIF file. For more information, see [AUTOTITLE](/code-security/how-tos/scan-code-for-vulnerabilities/integrate-with-existing-tools/uploading-a-sarif-file-to-github).

content/code-security/concepts/code-scanning/sarif-files.md

@@ -35,7 +35,7 @@ If the lines of code changed in the pull request generate {% data variables.prod
 * The **Files changed** tab of the pull request
 
 > [!NOTE]
-> {% data variables.product.prodname_code_scanning_caps %} displays alerts in pull requests only when all the lines of code identified by the alert exist in the pull request diff. For more information, see [AUTOTITLE](/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning#specifying-the-location-for-source-files).
+> {% data variables.product.prodname_code_scanning_caps %} displays alerts in pull requests only when all the lines of code identified by the alert exist in the pull request diff. For more information, see [AUTOTITLE](/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning#source-file-locations).
 
 {% ifversion code-scanning-autofix %}