Merge pull request #40858 from github/repo-sync

Repo sync

Author: docs-bot

.github/workflows/test-changed-content.yml

@@ -51,4 +51,4 @@ jobs:
         env:
           CHANGED_FILES: ${{ steps.changed_files.outputs.filtered_changed_files }}
           DELETED_FILES: ${{ steps.changed_files.outputs.filtered_deleted_files }}
-        run: npm test -- src/content-render/tests/render-changed-and-deleted-files.js
+        run: npm test -- src/content-render/tests/render-changed-and-deleted-files.ts

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

@@ -50,7 +50,7 @@ To use a specific action version, users can configure their {% data variables.pr
 
 ### Using tags for release management
 
-{% ifversion immutable-releases-preview %}
+{% ifversion fpt or ghec %}
 > [!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/release-and-maintain-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 immutable-releases-preview %}
+    {% ifversion fpt or ghec %}
     > [!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/using-immutable-releases-and-tags-to-manage-your-actions-releases.md

@@ -3,16 +3,15 @@ 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:
-  feature: immutable-releases-preview
+  fpt: '*'
+  ghec: '*'
 topics:
   - Actions
   - Code Security
   - Vulnerabilities
   - Dependencies
 ---
 
-{% data reusables.releases.immutable-releases-preview-note %}
-
 If you enable immutable releases on your action's repository, you can manage your action's releases as follows:
 
 1. To start the release cycle, develop and validate a potential release for your action on a release branch.

content/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds.md

@@ -59,7 +59,7 @@ How exactly you sign your build will depend on what sort of code you're writing,
 
 For more information, see [AUTOTITLE](/actions/security-guides/encrypted-secrets){% ifversion fpt or ghec %}, [AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect),{% endif %} and [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners).
 
-{% ifversion immutable-releases-preview %}
+{% ifversion fpt or ghec %}
 
 ## Use immutable releases
 

content/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases.md

@@ -2,24 +2,43 @@
 title: Immutable releases
 intro: 'Learn about immutable releases and how they can help you maintain the integrity of your software supply chain.'
 versions:
-  feature: immutable-releases-preview
+  fpt: '*'
+  ghec: '*'
 type: overview
 topics:
   - Code Security
   - Vulnerabilities
   - Dependencies
 ---
 
-{% data reusables.releases.immutable-releases-preview-note %}
+**Immutable releases** are releases where the assets and associated Git tag cannot be changed after publication. The use of this type of release increases security by blocking supply chain attacks. Attackers cannot:
+* Inject vulnerabilities or malware into current project releases.
+* Make changes to assets and tags that may break developer workflows.
 
-**Immutable releases** are releases where the assets and associated Git tag cannot be changed after publication. They increase security by blocking:
-* Supply chain attacks where attackers inject vulnerabilities or malware into current project releases
-* Accidental changes to assets and tags that may break developer workflows
+## What immutable releases protect
+
+When you enable immutable releases, the following protections are enforced:
+
+* **Git tags cannot be moved or deleted**: Once an immutable release is published, its associated Git tag is locked to a specific commit and cannot be changed or removed.
+* **Release assets cannot be modified or deleted**: All files attached to the release (such as binaries and archives) are protected from modification or deletion.
 
 Additionally, creating an immutable release automatically generates a **release attestation**, which is a cryptographically verifiable record of a release containing the release tag, commit SHA, and release assets. Consumers can use this attestation to make sure the releases and artifacts they are using exactly match the published {% data variables.product.github %} releases.
 
+> [!NOTE]
+> Immutable releases include protection against repository resurrection attacks. Even if you delete a repository and create a new one with the same name, you cannot reuse tags that were associated with immutable releases in the original repository.
+
 If a release is immutable, you will see "{% octicon "lock" aria-hidden="true" %} Immutable"  below the title on the release page.
 
+## Best practices for publishing immutable releases
+
+We recommend you use the following workflow for publishing an immutable release.
+
+1. Create the release as a draft.
+1. Attach all associated assets to the draft release.
+1. Publish the draft release.
+
+This ensures that all assets are in place before the release becomes immutable, preventing the need to work around immutability restrictions.
+
 ## Next steps
 
 To learn how to enable immutable releases for your repository or organization, see [AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/preventing-changes-to-your-releases).

content/code-security/supply-chain-security/understanding-your-software-supply-chain/preventing-changes-to-your-releases.md

@@ -3,16 +3,15 @@ title: Preventing changes to your releases
 shortTitle: Prevent release changes
 intro: 'You can enforce immutable releases for a repository or organization to prevent potential vulnerabilities.'
 versions:
-  feature: immutable-releases-preview
+  fpt: '*'
+  ghec: '*'
 type: overview
 topics:
   - Code Security
   - Vulnerabilities
   - Dependencies
 ---
 
-{% data reusables.releases.immutable-releases-preview-note %}
-
 ## Enforcing immutable releases for your repository
 
 {% data reusables.repositories.navigate-to-repo %}

content/code-security/supply-chain-security/understanding-your-software-supply-chain/verifying-the-integrity-of-a-release.md

@@ -3,7 +3,8 @@ title: Verifying the integrity of a release
 shortTitle: Verify release integrity
 intro: 'You can avoid tampering and accidental changes by ensuring the releases you use have not been modified after publication.'
 versions:
-  feature: immutable-releases-preview
+  fpt: '*'
+  ghec: '*'
 type: overview
 topics:
   - Code Security
@@ -12,8 +13,6 @@ topics:
 defaultTool: cli
 ---
 
-{% data reusables.releases.immutable-releases-preview-note %}
-
 {% cli %}
 
 ## Prerequisites

content/copilot/concepts/auto-model-selection.md

@@ -17,7 +17,7 @@ contentType: concepts
 
 Experience less rate limiting and reduce the mental load of choosing a model by letting {% data variables.copilot.copilot_auto_model_selection %} automatically choose the best available model.  
 
-In {% data variables.product.prodname_vscode_shortname %}, {% data variables.copilot.copilot_auto_model_selection %} chooses from {% data variables.copilot.copilot_gpt_41 %}, {% data variables.copilot.copilot_gpt_5_mini %}, {% data variables.copilot.copilot_gpt_5 %}, {% data variables.copilot.copilot_claude_sonnet_35 %}, and {% data variables.copilot.copilot_claude_sonnet_40 %}, based on availability and to help reduce rate limiting. Included models may change over time.
+In {% data variables.product.prodname_vscode_shortname %}, {% data variables.copilot.copilot_auto_model_selection %} chooses from {% data variables.copilot.copilot_gpt_41 %}, {% data variables.copilot.copilot_gpt_5_mini %}, {% data variables.copilot.copilot_gpt_5 %}, {% data variables.copilot.copilot_claude_sonnet_35 %}, and {% data variables.copilot.copilot_claude_sonnet_45 %}, based on availability and to help reduce rate limiting. Included models may change over time.
 
 Automatically selected models **won't** include these models:
 * Models with premium request multipliers greater than one. See [AUTOTITLE](/copilot/reference/ai-models/supported-models#model-multipliers).

content/repositories/releasing-projects-on-github/managing-releases-in-a-repository.md

@@ -31,6 +31,13 @@ You can choose whether {% data variables.large_files.product_name_long %} ({% da
 
 ## Creating a release
 
+{% ifversion fpt or ghec %}
+
+> [!TIP]
+> If you have enabled immutable releases for your repository, it's recommended to create releases as drafts first, attach all assets, and then publish. This ensures all assets are in place before the release becomes immutable. For more information, see [AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases).
+
+{% endif %}
+
 {% webui %}
 
 {% data reusables.repositories.navigate-to-repo %}
@@ -67,9 +74,11 @@ If you @mention any {% data variables.product.github %} users in the notes, the
 
 ## Editing a release
 
-{% ifversion immutable-releases-preview %}
+{% ifversion fpt or ghec %}
+
 > [!NOTE]
 > If you have enabled immutable releases for your repository, you can only edit the title and release notes after a release is published. See [AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases).
+
 {% endif %}
 
 {% webui %}