Merge pull request #43422 from github/repo-sync

Repo sync

Author: docs-bot

content/actions/concepts/security/kubernetes-admissions-controller.md

@@ -23,7 +23,7 @@ To [install the controller](/actions/how-tos/security-for-github-actions/using-a
 
 When the Policy Controller is installed, it will intercept all image pull requests and verify the attestation for the image. The attestation must be stored in the image registry as an [OCI attached artifact](https://oras.land/docs/concepts/reftypes/) containing a [Sigstore Bundle](https://docs.sigstore.dev/about/bundle/) which contains the attestation and cryptographic material (e.g. certificates and signatures) used to verify the attestation. A verification process is then performed that ensures the image was built with the specified build provenance and matches any policies enabled by the cluster administrator.
 
-In order for an image to be verifiable, it must have a valid provenance attestation in the registry, which can be done by enabling the `push-to-registry: true` attribute in the `actions/attest-build-provenance` action. See [Generating build provenance for container images](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds#generating-build-provenance-for-container-images) for more details on how to generate attestations for container images.
+In order for an image to be verifiable, it must have a valid provenance attestation in the registry, which can be done by enabling the `push-to-registry: true` attribute in the `actions/attest` action. See [Generating build provenance for container images](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds#generating-build-provenance-for-container-images) for more details on how to generate attestations for container images.
 
 ### About trust roots and policies
 

content/actions/how-tos/secure-your-work/use-artifact-attestations/enforce-artifact-attestations.md

@@ -14,7 +14,7 @@ category:
 contentType: how-tos
 ---
 
->[!NOTE] Before proceeding, ensure you have enabled build provenance for container images, including setting the `push-to-registry` attribute in the [`attest-build-provenance` action](https://github.com/actions/attest-build-provenance) as documented in [Generating build provenance for container images](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds#generating-build-provenance-for-container-images). This is required for the Policy Controller to verify the attestation.
+> [!NOTE] Before proceeding, ensure you have enabled build provenance for container images, including setting the `push-to-registry` attribute in the [`attest` action](https://github.com/actions/attest) as documented in [Generating build provenance for container images](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds#generating-build-provenance-for-container-images). This is required for the Policy Controller to verify the attestation.
 
 ## Getting started with Kubernetes admission controller
 

content/actions/how-tos/secure-your-work/use-artifact-attestations/increase-security-rating.md

@@ -51,7 +51,7 @@ To verify the artifact attestations generated with your builds, you can use [`gh
 The `gh attestation verify` command requires either `--owner` or `--repo` flags to be used with it. These flags do two things.
 
 * They tell `gh attestation verify` where to fetch the attestation from. This will always be your caller workflow.
-* They tell `gh attestation verify` where the workflow that did the signing came from. This will always be the workflow that uses [`attest-build-provenance` action](https://github.com/actions/attest-build-provenance), which may be a reusable workflow.
+* They tell `gh attestation verify` where the workflow that did the signing came from. This will always be the workflow that uses the [`attest` action](https://github.com/actions/attest), which may be a reusable workflow.
 
 You can use optional flags with the `gh attestation verify` command.
 

content/actions/how-tos/secure-your-work/use-artifact-attestations/manage-attestations.md

@@ -32,8 +32,8 @@ Use the `created` filter to filter by creation date. To enter a custom date rang
 
 Use the `predicate` filter to filter by the kind of attestation. A predicate is the type of claim that an attestation makes about an artifact, such as "this artifact was built during a particular workflow run and originates from this repository."
 
-* Provenance attestations were created with the `attest-build-provenance` action.
-* SBOM attestations were created with the `attest-sbom` action.
+* Provenance attestations were created with the `attest` action.
+* SBOM attestations were created with the `attest` action using the `sbom-path` input.
 * Custom predicate type patterns are **not** supported in the search field, but are supported by the API.
 
 ## Deleting attestations

content/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations.md

@@ -26,9 +26,9 @@ You can use {% data variables.product.prodname_actions %} to generate artifact a
 To generate an artifact attestation, you must:
 
 * Ensure you have the appropriate permissions configured in your workflow.
-* Include a step in your workflow that uses the [`attest-build-provenance` action](https://github.com/actions/attest-build-provenance).
+* Include a step in your workflow that uses the [`attest` action](https://github.com/actions/attest).
 
-When you run your updated workflows, they will build your artifacts and generate an artifact attestation that establishes build provenance. You can view attestations in your repository's **Actions** tab. For more information, see the [`attest-build-provenance`](https://github.com/actions/attest-build-provenance) repository.
+When you run your updated workflows, they will build your artifacts and generate an artifact attestation that establishes build provenance. You can view attestations in your repository's **Actions** tab. For more information, see the [`attest`](https://github.com/actions/attest) repository.
 
 ### Generating build provenance for binaries
 
@@ -45,7 +45,7 @@ When you run your updated workflows, they will build your artifacts and generate
 
    ```yaml
    - name: Generate artifact attestation
-     uses: actions/attest-build-provenance@v3
+     uses: actions/attest@v4
      with:
        subject-path: 'PATH/TO/ARTIFACT'
    ```
@@ -68,7 +68,7 @@ When you run your updated workflows, they will build your artifacts and generate
 
    ```yaml
    - name: Generate artifact attestation
-     uses: actions/attest-build-provenance@v3
+     uses: actions/attest@v4
      with:
        subject-name: {% raw %}${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}{% endraw %}
        subject-digest: 'sha256:fedcba0...'
@@ -87,9 +87,9 @@ To generate an attestation for an SBOM, you must:
 
 * Ensure you have the appropriate permissions configured in your workflow.
 * Create an SBOM for your artifact. For more information, see [`anchore-sbom-action`](https://github.com/marketplace/actions/anchore-sbom-action) in the {% data variables.product.prodname_marketplace %}.
-* Include a step in your workflow that uses the [`attest-sbom` action](https://github.com/actions/attest-sbom).
+* Include a step in your workflow that uses the [`attest` action](https://github.com/actions/attest) with the `sbom-path` input.
 
-When you run your updated workflows, they will build your artifacts and generate an SBOM attestation. You can view attestations in your repository's **Actions** tab. For more information, see the [`attest-sbom` action](https://github.com/actions/attest-sbom) repository.
+When you run your updated workflows, they will build your artifacts and generate an SBOM attestation. You can view attestations in your repository's **Actions** tab. For more information, see the [`attest`](https://github.com/actions/attest) repository.
 
 ### Generating an SBOM attestation for binaries
 
@@ -106,7 +106,7 @@ When you run your updated workflows, they will build your artifacts and generate
 
    ```yaml
    - name: Generate SBOM attestation
-     uses: actions/attest-sbom@v2
+     uses: actions/attest@v4
      with:
        subject-path: 'PATH/TO/ARTIFACT'
        sbom-path: 'PATH/TO/SBOM'
@@ -130,7 +130,7 @@ When you run your updated workflows, they will build your artifacts and generate
 
    ```yaml
    - name: Generate SBOM attestation
-     uses: actions/attest-sbom@v2
+     uses: actions/attest@v4
      with:
        subject-name: {% raw %}${{ env.REGISTRY }}/PATH/TO/IMAGE{% endraw %}
        subject-digest: 'sha256:fedcba0...'
@@ -180,7 +180,7 @@ gh attestation verify oci://ghcr.io/ORGANIZATION_NAME/IMAGE_NAME:test -R ORGANIZ
 
 To verify SBOM attestations, you have to provide the `--predicate-type` flag to reference a non-default predicate. For more information, see [Vetted predicates](https://github.com/in-toto/attestation/tree/main/spec/predicates#vetted-predicates) in the `in-toto/attestation` repository.
 
-For example, the [`attest-sbom` action](https://github.com/actions/attest-sbom) currently supports either SPDX or CycloneDX SBOM predicates. To verify an SBOM attestation in the SPDX format, you can use the following {% data variables.product.prodname_cli %} command.
+For example, the [`attest` action](https://github.com/actions/attest) currently supports either SPDX or CycloneDX SBOM predicates. To verify an SBOM attestation in the SPDX format, you can use the following {% data variables.product.prodname_cli %} command.
 
 ```bash copy
 gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY \

content/actions/tutorials/publish-packages/publish-docker-images.md

@@ -115,7 +115,7 @@ jobs:
 
 {% ifversion artifact-attestations %}
       - name: Generate artifact attestation
-        uses: actions/attest-build-provenance@v3
+        uses: actions/attest@v4
         with:
           subject-name: index.docker.io/my-docker-hub-namespace/my-docker-hub-repository
           subject-digest: {% raw %}${{ steps.push.outputs.digest }}{% endraw %}

content/code-security/how-tos/secure-your-supply-chain/establish-provenance-and-integrity/upload-linked-artifacts.md

@@ -77,7 +77,7 @@ You can upload data to the {% data variables.product.virtual_registry %} in the
 
 In the following example, we build and publish a Docker image, then use the `{% raw %}${{ steps.push.outputs.digest }}{% endraw %}` output in the next step to generate a provenance attestation.
 
-The `attest-build-provenance` action automatically uploads a storage record to the {% data variables.product.virtual_registry %} when `push-to-registry: true` is set and the workflow includes the `artifact-metadata: write` permission.
+The `attest` action automatically uploads a storage record to the {% data variables.product.virtual_registry %} when `push-to-registry: true` is set and the workflow includes the `artifact-metadata: write` permission.
 
 ``` yaml
 {% raw %}
@@ -108,7 +108,7 @@ jobs:
             ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }}:${{ github.sha }}
 
       - name: Generate artifact attestation
-        uses: actions/attest-build-provenance@v3
+        uses: actions/attest@v4
         with:
           subject-name: ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }}
           subject-digest: ${{ steps.push.outputs.digest }}

content/copilot/concepts/fallback-and-lts-models.md

@@ -0,0 +1,49 @@
+---
+title: Base and long-term support (LTS) models
+shortTitle: Base and LTS models
+intro: 'Learn about base models, long-term support (LTS) models, and how they affect model availability for enterprises using {% data variables.product.prodname_copilot %}.'
+versions:
+  feature: copilot
+allowTitleToDifferFromFilename: true
+contentType: concepts
+category:
+  - Manage Copilot for a team
+---
+
+## About base models
+
+> [!IMPORTANT]
+> * On March 18, 2026, {% data variables.product.github %} designated {% data variables.copilot.copilot_gpt_53_codex %} as the base model.
+> * Base models apply only to {% data variables.copilot.copilot_business_short %} and {% data variables.copilot.copilot_enterprise_short %}.
+
+ A base model is the default AI model that {% data variables.product.prodname_copilot %} uses when no other models are enabled. The base model is automatically enabled for all {% data variables.copilot.copilot_business_short %} or {% data variables.copilot.copilot_enterprise_short %} accounts within 60 days after the model is designated as a base model.
+
+When a new model is designated a base model, the following timeline applies:
+
+| Phase              | Timeline                      | What happens                                                                                       |
+|--------------------|-------------------------------|----------------------------------------------------------------------------------------------------|
+| Announcement       | Day 0                         | {% data variables.product.github %} announces the new base model.                              |
+| Upgrade window     | Day 0 to Day 60               | Customers have 60 days to upgrade their IDE extensions to versions that support the new model.     |
+| Enablement         | Day 60                        | The new model is automatically enabled on all organizations and enterprises as the base model. |
+
+> [!NOTE]
+> The base model has a **1x premium request multiplier** on paid plans. For more information about multipliers, see [AUTOTITLE](/copilot/concepts/billing/copilot-requests#model-multipliers).
+
+## About long-term support (LTS) models
+
+> [!IMPORTANT]
+> * On March 18, 2026, {% data variables.product.github %} designated {% data variables.copilot.copilot_gpt_53_codex %} as the LTS model.
+> * LTS models apply only to {% data variables.copilot.copilot_business_short %} and {% data variables.copilot.copilot_enterprise_short %}.
+
+An LTS model is an AI model that {% data variables.product.github %} commits to supporting for an extended period of one year from its designation date. During that period, the model remains available, which allows users to build around the model without concern that it will be {% data variables.release-phases.closing_down %} unexpectedly.
+
+## Continuous access when premium requests are unavailable
+
+{% data variables.copilot.copilot_gpt_53_codex %} is available on paid plans with a 0x premium request multiplier, which means it does not consume premium requests. This ensures continuous access to {% data variables.product.prodname_copilot_short %} in situations such as:
+* Premium request quota exhausted: If a user has used their monthly premium request allowance, they can continue working with {% data variables.copilot.copilot_gpt_53_codex %} at no additional cost.
+* Overage controls disabled: If an organization or enterprise has disabled premium request overages and a user reaches their limit, {% data variables.copilot.copilot_gpt_53_codex %} remains available.
+
+## Further reading
+
+* [AUTOTITLE](/copilot/reference/ai-models/supported-models)
+* [AUTOTITLE](/copilot/concepts/billing/copilot-requests)

content/copilot/concepts/index.md

@@ -20,5 +20,6 @@ children:
   - /policies
   - /mcp-management
   - /network-settings
+  - /fallback-and-lts-models
 contentType: concepts
 ---

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

@@ -102,6 +102,10 @@ For more information about premium requests, see [AUTOTITLE](/copilot/managing-c
 
 {% data reusables.copilot.model-multipliers %}
 
+## Fallback and long-term support (LTS) models
+
+For more information about fallback and LTS models, see [AUTOTITLE](/copilot/concepts/fallback-and-lts-models).
+
 ## Next steps
 
 * For task-based guidance on selecting a model, see [AUTOTITLE](/copilot/reference/ai-models/model-comparison).