Merge branch 'main' into patch-2

Author: Sharra-writes

.npmrc

@@ -2,3 +2,4 @@
 # https://www.peterbe.com/plog/benchmarking-npm-install-with-or-without-audit
 # Also we have Dependabot alerts configured in the GitHub repo.
 audit=false
+fund=false

CHANGELOG.md

@@ -1,5 +1,10 @@
 # Docs changelog
 
+**23 February 2026**
+
+Added a new how-to article, [Automating tasks with Copilot CLI and GitHub Actions](https://docs.github.com/en/copilot/how-tos/copilot-cli/automate-with-actions), that walks through how to run Copilot CLI inside a GitHub Actions workflow in non-interactive (programmatic) mode. The article covers the full pattern—trigger, setup, install, authenticate, and run—and includes an example workflow that generates a daily summary of repository changes.
+<hr>
+
 **17 February 2026**
 
 We’ve added a new tutorial, "[Using hooks with Copilot CLI for predictable, policy-compliant execution](https://docs.github.com/en/copilot/tutorials/copilot-cli-hooks)", to help teams configure repository-scoped hooks that log prompts and tool usage, enforce guardrails with `preToolUse`, and roll out policies safely across repositories.

assets/images/help/billing/cost-center-example-2.png

@@ -50,7 +50,7 @@ To use a specific action version, users can configure their {% data variables.pr
 
 ### Using tags for release management
 
-{% ifversion fpt or ghec %}
+{% ifversion immutable-releases %}
 > [!NOTE] If you have enabled immutable releases to help prevent supply chain attacks and accidental changes to your releases, instead see [AUTOTITLE](/actions/how-tos/create-and-publish-actions/using-immutable-releases-and-tags-to-manage-your-actions-releases).
 {% endif %}
 

content/actions/how-tos/create-and-publish-actions/manage-custom-actions.md

@@ -55,7 +55,7 @@ To support the developer process in the next section, add two {% data variables.
 1. Add a workflow that triggers when a commit is pushed to a feature branch or to `main` or when a pull request is created. Configure the workflow to run your unit and integration tests. For an example, see [this workflow](https://github.com/actions/javascript-action/blob/main/.github/workflows/ci.yml).
 1. Add a workflow that triggers when a release is published or edited. Configure the workflow to ensure semantic tags are in place. You can use an action like [JasonEtco/build-and-tag-action](https://github.com/JasonEtco/build-and-tag-action) to compile and bundle the JavaScript and metadata file and force push semantic major, minor, and patch tags. For more information about semantic tags, see [About semantic versioning](https://docs.npmjs.com/about-semantic-versioning).
 
-    {% ifversion fpt or ghec %}
+    {% ifversion immutable-releases %}
     > [!NOTE]
     > If you enable immutable releases for your repository, you cannot use this action to force push tags tied to releases on {% data variables.product.github %}. To learn how to manage your releases with immutable releases, see [AUTOTITLE](/actions/how-tos/create-and-publish-actions/using-immutable-releases-and-tags-to-manage-your-actions-releases).
     {% endif %}

content/actions/how-tos/create-and-publish-actions/release-and-maintain-actions.md

@@ -3,8 +3,7 @@ title: Using immutable releases and tags to manage your action's releases
 shortTitle: Use immutable releases
 intro: 'Learn how you can use a combination of immutable releases on {% data variables.product.github %} and Git tags to manage your action''s releases.'
 versions:
-  fpt: '*'
-  ghec: '*'
+  feature: immutable-releases
 topics:
   - Actions
   - Code Security

content/actions/how-tos/create-and-publish-actions/using-immutable-releases-and-tags-to-manage-your-actions-releases.md

@@ -38,7 +38,7 @@ When combined with OpenID Connect (OIDC), reusable workflows let you enforce con
 
 ## How the token works with reusable workflows
 
-During a workflow run, {% data variables.product.prodname_dotcom %}'s OIDC provider presents a OIDC token to the cloud provider which contains information about the job. If that job is part of a reusable workflow, the token will include the standard claims that contain information about the calling workflow, and will also include a custom claim called `job_workflow_ref` that contains information about the called workflow.
+During a workflow run, {% data variables.product.prodname_dotcom %}'s OIDC provider presents an OIDC token to the cloud provider which contains information about the job. If that job is part of a reusable workflow, the token will include the standard claims that contain information about the calling workflow, and will also include a custom claim called `job_workflow_ref` that contains information about the called workflow.
 
 For example, the following OIDC token is for a job that was part of a called workflow. The `workflow`, `ref`, and other attributes describe the caller workflow, while `job_workflow_ref` refers to the called workflow:
 

content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-with-reusable-workflows.md

@@ -122,7 +122,7 @@ In addition to runner environment variables, {% data variables.product.prodname_
 
 The `run` steps in a workflow, or in a referenced action, are processed by a runner. As a result, you can use runner environment variables here, using the appropriate syntax for the shell you are using on the runner - for example, `$NAME` for the bash shell on a Linux runner, or `$env:NAME` for PowerShell on a Windows runner. In most cases you can also use contexts, with the syntax {% raw %}`${{ CONTEXT.PROPERTY }}`{% endraw %}, to access the same value. The difference is that the context will be interpolated and replaced by a string before the job is sent to a runner.
 
-However, you cannot use runner environment variables in parts of a workflow that are processed by {% data variables.product.prodname_actions %} and are not sent to the runner. Instead, you must use contexts. For example, an `if` conditional, which determines whether a job or step is sent to the runner, is always processed by {% data variables.product.prodname_actions %}. You must therefore use a context in an `if` conditional statement to access the value of an variable.
+However, you cannot use runner environment variables in parts of a workflow that are processed by {% data variables.product.prodname_actions %} and are not sent to the runner. Instead, you must use contexts. For example, an `if` conditional, which determines whether a job or step is sent to the runner, is always processed by {% data variables.product.prodname_actions %}. You must therefore use a context in an `if` conditional statement to access the value of a variable.
 
 {% raw %}
 

content/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables.md

@@ -42,6 +42,7 @@ These limits are subject to change.
 | Larger runners | Private IP scaling for vnet injection | 30% buffer | You need a buffer to accommodate the maximum job concurrency you anticipate. See [Private IP scaling for vnet injection on larger runners](#private-ip-scaling-for-vnet-injection-on-larger-runners). | {% octicon "check" aria-label="Yes" %} Configurable Azure virtual network |
 | Dependency caching | Uploads per minute | 200 per minute | Each repository is limited to 200 cache entry uploads per minute. If this limit is exceeded, subsequent cache upload attempts will fail until the rate limit resets. | {% octicon "x" aria-label="No" %} |
 | Dependency caching | Downloads per minute | 1500 per minute | Each repository is limited to 1500 cache entry downloads per minute. If this limit is exceeded, subsequent cache download attempts will fail until the rate limit resets. | {% octicon "x" aria-label="No" %} |
+| Dependency caching | Deletes per minute | 400 per minute | Each repository is limited to 400 cache delete operations per minute. If this limit is exceeded, subsequent cache delete attempts will fail until the rate limit resets. Each request to delete caches either by key or by ID counts towards this limit. | {% octicon "x" aria-label="No" %} |
 
 ### Job concurrency limits for {% data variables.product.github %}-hosted runners
 

content/actions/reference/limits.md

@@ -14,7 +14,7 @@ shortTitle: Releases
 
 ## Releases of {% data variables.product.prodname_ghe_server %}
 
-{% data variables.product.company_short %} supports the **four** most recent feature releases.
+{% data variables.product.company_short %} supports at least the **four** most recent feature releases.
 
 We provide documentation for both supported and unsupported versions of {% data variables.product.prodname_ghe_server %}. We do not maintain or update the documentation for unsupported versions.
 
@@ -58,6 +58,7 @@ If you run analysis in an external CI system, we recommend using the same versio
 
 | {% data variables.product.prodname_ghe_server %} version | Recommended {% data variables.product.prodname_codeql_cli %} version |
 | ------------------------------------------------- | ---------------------- |
+| 3.20 | 2.23.9 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.23.9/)) |
 | 3.19 | 2.22.4 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.22.4/)) |
 | 3.18 | 2.21.4 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.21.4/)) |
 | 3.17 | 2.20.7 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.20.7/)) |
@@ -79,6 +80,7 @@ For instances with {% data variables.product.prodname_actions %} enabled, self-h
 
 | {% data variables.product.prodname_ghe_server %} version | Minimum Runner version |
 | ------------------------------------------------- | ---------------------- |
+| 3.20 | 2.330.0 ([release notes](https://github.com/actions/runner/releases/tag/v2.330.0)) |
 | 3.19 | 2.328.0 ([release notes](https://github.com/actions/runner/releases/tag/v2.328.0)) |
 | 3.18 | 2.324.0 ([release notes](https://github.com/actions/runner/releases/tag/v2.324.0)) |
 | 3.17 | 2.322.0 ([release notes](https://github.com/actions/runner/releases/tag/v2.322.0)) |