Merge pull request #34050 from github/repo-sync

Repo sync

.github/workflows/azure-preview-env-deploy-public.yml

@@ -66,7 +66,7 @@ jobs:
           password: ${{ secrets.NONPROD_REGISTRY_PASSWORD }}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@d70bba72b1f3fd22344832f00baa16ece964efeb
+        uses: docker/setup-buildx-action@4fd812986e6c8c2a69e18311145f9371337f27d4
 
       - name: Check out main branch
         uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

.github/workflows/azure-preview-env-deploy.yml

@@ -79,7 +79,7 @@ jobs:
           password: ${{ secrets.NONPROD_REGISTRY_PASSWORD }}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@d70bba72b1f3fd22344832f00baa16ece964efeb
+        uses: docker/setup-buildx-action@4fd812986e6c8c2a69e18311145f9371337f27d4
 
       - name: Check out PR code
         uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

.github/workflows/azure-prod-build-deploy.yml

@@ -49,7 +49,7 @@ jobs:
           password: ${{ secrets.PROD_REGISTRY_PASSWORD }}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@d70bba72b1f3fd22344832f00baa16ece964efeb
+        uses: docker/setup-buildx-action@4fd812986e6c8c2a69e18311145f9371337f27d4
 
       - name: Check out repo
         uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

.github/workflows/azure-staging-build-deploy.yml

@@ -57,7 +57,7 @@ jobs:
           password: ${{ secrets.NONPROD_REGISTRY_PASSWORD }}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@d70bba72b1f3fd22344832f00baa16ece964efeb
+        uses: docker/setup-buildx-action@4fd812986e6c8c2a69e18311145f9371337f27d4
 
       - name: Check out repo
         uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

.github/workflows/main-preview-docker-cache.yml

@@ -42,7 +42,7 @@ jobs:
           password: ${{ secrets.NONPROD_REGISTRY_PASSWORD }}
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@d70bba72b1f3fd22344832f00baa16ece964efeb
+        uses: docker/setup-buildx-action@4fd812986e6c8c2a69e18311145f9371337f27d4
 
       - name: Check out repo
         uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

content/actions/deployment/about-deployments/about-continuous-deployment.md

@@ -27,7 +27,7 @@ You can set up a {% data variables.product.prodname_actions %} workflow to deplo
 
 You can configure your CD workflow to run when a {% data variables.product.product_name %} event occurs (for example, when new code is pushed to the default branch of your repository), on a set schedule, manually, or when an external event occurs using the repository dispatch webhook. For more information about when your workflow can run, see "[AUTOTITLE](/actions/using-workflows/events-that-trigger-workflows)."
 
-{% data variables.product.prodname_actions %} provides features that give you more control over deployments. For example, you can use environments to require approval for a job to proceed, restrict which branches can trigger a workflow, or limit access to secrets. You can use concurrency to limit your CD pipeline to a maximum of one in-progress deployment and one pending deployment. For more information about these features, see "[AUTOTITLE](/actions/deployment/about-deployments/deploying-with-github-actions)" and "[AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment)."
+{% data variables.product.prodname_actions %} provides features that give you more control over deployments. For example, you can use environments to require approval for a job to proceed, restrict which branches can trigger a workflow, or limit access to secrets. You can use concurrency to limit your CD pipeline to a maximum of one in-progress deployment and one pending deployment. For more information about these features, see "[AUTOTITLE](/actions/deployment/about-deployments/deploying-with-github-actions)" and "[AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment)."
 
 ## Using OpenID Connect to access cloud resources
 
@@ -40,5 +40,5 @@ You can configure your CD workflow to run when a {% data variables.product.produ
 ## Further reading
 
 * [AUTOTITLE](/actions/deployment/about-deployments/deploying-with-github-actions)
-* [AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment){% ifversion fpt or ghec %}
+* [AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment){% ifversion fpt or ghec %}
 * "[AUTOTITLE](/billing/managing-billing-for-github-actions)"{% endif %}

content/actions/deployment/protecting-deployments/configuring-custom-deployment-protection-rules.md

@@ -19,7 +19,7 @@ topics:
 
 Custom deployment protection rules are powered by {% data variables.product.prodname_github_apps %}. Once a deployment protection rule is configured and installed in a repository, it can be enabled for any environments in the repository.
 
-After you enable a custom deployment protection rule on an environment, every time a workflow step targets that environment, the deployment protection rule will run automatically. For more information about targeting an environment for deployments, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment)."
+After you enable a custom deployment protection rule on an environment, every time a workflow step targets that environment, the deployment protection rule will run automatically. For more information about targeting an environment for deployments, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment)."
 
 When a custom deployment protection rule is triggered it will wait for up to 30 days for a webhook event response before it times out and the workflow job fails.
 

content/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect.md

@@ -178,7 +178,7 @@ The following examples demonstrate how to use "Subject" as a condition, and expl
 
 The subject claim includes the environment name when the job references an environment.
 
-You can configure a subject that filters for a specific [environment](/actions/deployment/targeting-different-environments/using-environments-for-deployment) name. In this example, the workflow run must have originated from a job that has an environment named `Production`, in a repository named `octo-repo` that is owned by the `octo-org` organization:
+You can configure a subject that filters for a specific [environment](/actions/deployment/targeting-different-environments/managing-environments-for-deployment) name. In this example, the workflow run must have originated from a job that has an environment named `Production`, in a repository named `octo-repo` that is owned by the `octo-org` organization:
 
 * Syntax: `repo:<orgName/repoName>:environment:<environmentName>`
 * Example: `repo:octo-org/octo-repo:environment:Production`

content/actions/deployment/targeting-different-environments/index.md

@@ -7,6 +7,6 @@ versions:
   ghes: '*'
   ghec: '*'
 children:
-  - /using-environments-for-deployment
+  - /managing-environments-for-deployment
 ---
 

content/actions/deployment/targeting-different-environments/using-environments-for-deployment.md → content/actions/deployment/targeting-different-environments/managing-environments-for-deployment.md

@@ -1,12 +1,14 @@
 ---
-title: Using environments for deployment
-shortTitle: Use environments for deployment
-intro: You can configure environments with protection rules and secrets. A workflow job that references an environment must follow any protection rules for the environment before running or accessing the environment's secrets.
+title: Managing environments for deployment
+shortTitle: Manage environments
+intro: You can create environments and secure those environments with deployment protection rules. A job that references an environment must follow any protection rules for the environment before running or accessing the environment's secrets.
 product: '{% data reusables.gated-features.environments %}'
+permissions: 'Repository owners'
 redirect_from:
   - /actions/reference/environments
   - /actions/deployment/environments
   - /actions/deployment/using-environments-for-deployment
+  - /actions/deployment/targeting-different-environments/using-environments-for-deployment
 topics:
   - CD
   - Deployment
@@ -204,7 +206,7 @@ Variables stored in an environment are only available to workflow jobs that refe
    1. Select the custom protection rule you want to enable.
    1. Click **Save protection rules**.
 {%- endif %}
-1. Optionally, specify what branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %} can deploy to this environment. For more information, see "[Deployment branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %}](/actions/deployment/targeting-different-environments/using-environments-for-deployment#deployment-branches{% ifversion deployment-protections-tag-patterns %}-and-tags{% endif %})."
+1. Optionally, specify what branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %} can deploy to this environment. For more information, see "[Deployment branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %}](/actions/deployment/targeting-different-environments/managing-environments-for-deployment#deployment-branches{% ifversion deployment-protections-tag-patterns %}-and-tags{% endif %})."
    1. Select the desired option in the **Deployment branches** dropdown.
    1. If you chose **Selected branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %}**, to add a new rule, click **Add deployment branch{% ifversion deployment-protections-tag-patterns %} or tag{% endif %} rule**
    {% ifversion deployment-protections-tag-patterns %}1. In the "Ref type" dropdown menu, depending on what rule you want to apply, click **{% octicon "git-branch" aria-label="The branch icon" %} Branch** or **{% octicon "tag" aria-label="The tag icon" %} Tag**.{% endif %}
@@ -230,14 +232,6 @@ You can also create and configure environments through the REST API. For more in
 
 Running a workflow that references an environment that does not exist will create an environment with the referenced name. The newly created environment will not have any protection rules or secrets configured. Anyone that can edit workflows in the repository can create environments via a workflow file, but only repository admins can configure the environment.
 
-## Using an environment
-
-Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. The job can access the environment's secrets only after the job is sent to a runner.
-
-When a workflow references an environment, the environment will appear in the repository's deployments. For more information about viewing current and previous deployments, see "[AUTOTITLE](/actions/deployment/managing-your-deployments/viewing-deployment-history)."
-
-{% data reusables.actions.environment-example %}
-
 ## Deleting an environment
 
 {% data reusables.actions.permissions-statement-environment %}

content/actions/managing-workflow-runs/reviewing-deployments.md

@@ -14,7 +14,7 @@ versions:
 
 Jobs that reference an environment configured with required reviewers will wait for an approval before starting. While a job is awaiting approval, it has a status of "Waiting". If a job is not approved within 30 days, it will automatically fail.
 
-For more information about environments and required approvals, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment)." For information about how to review deployments with the REST API, see "[AUTOTITLE](/rest/actions/workflow-runs)."
+For more information about environments and required approvals, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment)." For information about how to review deployments with the REST API, see "[AUTOTITLE](/rest/actions/workflow-runs)."
 
 ## Approving or rejecting a job
 
@@ -27,7 +27,7 @@ For more information about environments and required approvals, see "[AUTOTITLE]
 
 {% ifversion deployments-prevent-self-approval %}{% note %}
 
-**Note:** If the targeted environment is configured to prevent self-approvals for deployments, you will not be able to approve a deployment from a workflow run you initiated. For more information, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment#required-reviewers)."
+**Note:** If the targeted environment is configured to prevent self-approvals for deployments, you will not be able to approve a deployment from a workflow run you initiated. For more information, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment#required-reviewers)."
 
 {% endnote %}{% endif %}
 
@@ -41,7 +41,7 @@ If you have configured deployment protection rules that control whether software
 
 **Notes:**
 
-* You cannot bypass deployment protection rules if the environment has been configured to prevent admins from bypassing configured protection rules. For more information, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment#creating-an-environment)."
+* You cannot bypass deployment protection rules if the environment has been configured to prevent admins from bypassing configured protection rules. For more information, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment#creating-an-environment)."
 * You can only bypass deployment protection rules during workflow execution when a job referencing the environment is in a "Pending" state.
 
 {% endnote %}

content/actions/security-guides/security-hardening-for-github-actions.md

@@ -43,7 +43,7 @@ To help prevent accidental disclosure, {% data variables.product.product_name %}
   * Periodically review the registered secrets to confirm they are still required. Remove those that are no longer needed.
   * Rotate secrets periodically to reduce the window of time during which a compromised secret is valid.
 * **Consider requiring review for access to secrets**
-  * You can use required reviewers to protect environment secrets. A workflow job cannot access environment secrets until approval is granted by a reviewer. For more information about storing secrets in environments or requiring reviews for environments, see "[AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions)" and "[AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment)."
+  * You can use required reviewers to protect environment secrets. A workflow job cannot access environment secrets until approval is granted by a reviewer. For more information about storing secrets in environments or requiring reviews for environments, see "[AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions)" and "[AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment)."
 
 {% warning %}
 

content/actions/using-jobs/index.md

@@ -14,7 +14,7 @@ children:
   - /using-conditions-to-control-job-execution
   - /using-a-matrix-for-your-jobs
   - /using-concurrency
-  - /using-environments-for-jobs
+  - /using-environments-for-deployment
   - /running-jobs-in-a-container
   - /setting-default-values-for-jobs
   - /assigning-permissions-to-jobs

content/actions/using-jobs/using-environments-for-deployment.md

@@ -0,0 +1,25 @@
+---
+title: Using environments for deployment
+shortTitle: Environments
+intro: Specify a deployment environment in your workflow.
+versions:
+  fpt: '*'
+  ghes: '> 3.0'
+  ghec: '*'
+redirect_from:
+  - /actions/using-jobs/using-environments-for-jobs
+---
+
+{% data reusables.actions.enterprise-github-hosted-runners %}
+
+## About environments
+
+{% data reusables.actions.about-environments %}
+
+Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. The job can access the environment's secrets only after the job is sent to a runner.
+
+When a workflow references an environment, the environment will appear in the repository's deployments. For more information about viewing current and previous deployments, see "[AUTOTITLE](/actions/deployment/managing-your-deployments/viewing-deployment-history)."
+
+## Using an environment in a workflow
+
+{% data reusables.actions.environment-example %}

content/actions/using-workflows/about-workflows.md

@@ -206,4 +206,4 @@ To learn more about {% data variables.product.prodname_dotcom %}-hosted runner l
 
 ### Using environments
 
-You can configure environments with protection rules and secrets to control the execution of jobs in a workflow. Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. For more information, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment)."
+You can configure environments with protection rules and secrets to control the execution of jobs in a workflow. Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. For more information, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment)."

content/actions/using-workflows/reusing-workflows.md

@@ -172,7 +172,7 @@ You can define inputs and secrets, which can be passed from the caller workflow
 
    {% note %}
 
-   **Note**: Environment secrets are {% ifversion fpt or ghec %}encrypted {% endif %}strings that are stored in an environment that you've defined for a repository. Environment secrets are only available to workflow jobs that reference the appropriate environment. For more information, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment#environment-secrets)."
+   **Note**: Environment secrets are {% ifversion fpt or ghec %}encrypted {% endif %}strings that are stored in an environment that you've defined for a repository. Environment secrets are only available to workflow jobs that reference the appropriate environment. For more information, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment#environment-secrets)."
 
    {% endnote %}
 

content/actions/using-workflows/triggering-a-workflow.md

@@ -277,7 +277,7 @@ For more information about what information is available in the event context, s
 
 ### Using environments to manually trigger workflow jobs
 
-If you want to manually trigger a specific job in a workflow, you can use an environment that requires approval from a specific team or user. First, configure an environment with required reviewers. For more information, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment)." Then, reference the environment name in a job in your workflow using the `environment:` key. Any job referencing the environment will not run until at least one reviewer approves the job.
+If you want to manually trigger a specific job in a workflow, you can use an environment that requires approval from a specific team or user. First, configure an environment with required reviewers. For more information, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment)." Then, reference the environment name in a job in your workflow using the `environment:` key. Any job referencing the environment will not run until at least one reviewer approves the job.
 
 For example, the following workflow will run whenever there is a push to main. The `build` job will always run. The `publish` job will only run after the `build` job successfully completes (due to `needs: [build]`) and after all of the rules (including required reviewers) for the environment called `production` pass (due to `environment: production`).