Branch was updated using the 'autoupdate branch' Actions workflow.

content/actions/automating-builds-and-tests/about-continuous-integration.md

@@ -1,6 +1,6 @@
 ---
 title: About continuous integration
-intro: 'You can create custom continuous integration (CI) and continuous deployment (CD) workflows directly in your {% data variables.product.prodname_dotcom %} repository with {% data variables.product.prodname_actions %}.'
+intro: 'You can create custom continuous integration (CI) workflows directly in your {% data variables.product.prodname_dotcom %} repository with {% data variables.product.prodname_actions %}.'
 product: '{% data reusables.gated-features.actions %}'
 redirect_from:
   - /articles/about-continuous-integration
@@ -15,7 +15,6 @@ versions:
 type: overview
 topics:
   - CI
-  - CD
 shortTitle: Continuous integration
 ---
 
@@ -48,45 +47,12 @@ In addition to helping you set up CI workflows for your project, you can use {%
 
 For a definition of common terms, see "[Core concepts for {% data variables.product.prodname_actions %}](/github/automating-your-workflow-with-github-actions/core-concepts-for-github-actions)."
 
-## Supported languages
-<!-- If you make changes to this feature, update /getting-started-with-github/github-language-support to reflect any changes to supported languages. -->
+## Workflow templates
 
 {% data variables.product.product_name %} offers CI workflow templates for a variety of languages and frameworks.
 
 Browse the complete list of CI workflow templates offered by {% data variables.product.product_name %} in the {% ifversion fpt %}[actions/starter-workflows](https://github.com/actions/starter-workflows/tree/main/ci) repository{% else %} `actions/starter-workflows` repository on {% data variables.product.product_location %}{% endif %}.
 
-{% ifversion fpt or ghes > 3.0 or ghae-next %}
-## Skipping workflow runs
-
-If you want to temporarily prevent a workflow from being triggered, you can add a skip instruction to the commit message. Workflows that would otherwise be triggered `on: push` or `on: pull_request`, won't be triggered if you add any of the following strings to the commit message in a push, or the HEAD commit of a pull request:
-
-* `[skip ci]`
-* `[ci skip]`
-* `[no ci]`
-* `[skip actions]`
-* `[actions skip]`
-
-Alternatively, you can end the commit message with two empty lines followed by either `skip-checks: true` or `skip-checks:true`.
-
-You won't be able to merge the pull request if your repository is configured to require specific checks to pass first. To allow the pull request to be merged you can push a new commit to the pull request without the skip instruction in the commit message.
-
-{% note %}
-
-**Note:** Skip instructions only apply to the `push` and `pull_request` events. For example, adding `[skip ci]` to a commit message won't stop a workflow that's triggered `on: pull_request_target` from running.
-
-{% endnote %}
-{% endif %}
-
-## Notifications for workflow runs
-
-{% data reusables.repositories.workflow-notifications %}
-
-## Status badges for workflow runs
-
-{% data reusables.repositories.actions-workflow-status-badge-intro %}
-
-For more information, see "[Adding a workflow status badge](/actions/managing-workflow-runs/adding-a-workflow-status-badge)."
-
 ## Further reading
 
 {% ifversion fpt %}

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

@@ -0,0 +1,41 @@
+---
+title: About continuous deployment
+intro: 'You can create custom continuous deployment (CD) workflows directly in your {% data variables.product.prodname_dotcom %} repository with {% data variables.product.prodname_actions %}.'
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  fpt: '*'
+  ghes: '*'
+  ghae: '*'
+type: overview
+topics:
+  - CD
+shortTitle: Continuous deployment
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+
+## About continuous deployment
+
+_Continuous deployment_ (CD) is the practice of using automation to publish and deploy software updates. As part of the typical CD process, the code is automatically built and tested before deployment.
+
+Continuous deployment is often coupled with continuous integration. For more information about continuous integration, see "[About continuous integration](/actions/guides/about-continuous-integration)".
+
+## About continuous deployment using {% data variables.product.prodname_actions %}
+
+You can set up a {% data variables.product.prodname_actions %} workflow to deploy your software product. To verify that your product works as expected, your workflow can build the code in your repository and run your tests before deploying.
+
+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 "[Events that trigger workflows](/actions/reference/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 "[Deploying with GitHub Actions](/actions/deployment/deploying-with-github-actions)" and "[Using environments for deployment](/actions/deployment/using-environments-for-deployment)."
+
+## Workflow templates and third party actions
+
+{% data reusables.actions.cd-templates-actions %}
+
+## Further reading
+
+- [Deploying with GitHub Actions](/actions/deployment/deploying-with-github-actions)
+- [Using environments for deployment](/actions/deployment/using-environments-for-deployment){% ifversion fpt %}
+- "[Managing billing for {% data variables.product.prodname_actions %}](/billing/managing-billing-for-github-actions)"
+{% endif %}

content/actions/deployment/deploying-to-amazon-elastic-container-service.md

@@ -21,7 +21,7 @@ shortTitle: Deploy to Amazon ECS
 
 ## Introduction
 
-This guide explains how to use {% data variables.product.prodname_actions %} to build a containerized application, push it to [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/), and deploy it to [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/).
+This guide explains how to use {% data variables.product.prodname_actions %} to build a containerized application, push it to [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/), and deploy it to [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) when a release is created.
 
 On every new release in your {% data variables.product.company_short %} repository, the {% data variables.product.prodname_actions %} workflow builds and pushes a new container image to Amazon ECR, and then deploys a new task definition to Amazon ECS.
 
@@ -67,6 +67,8 @@ Before creating your {% data variables.product.prodname_actions %} workflow, you
 
    See the documentation for each action used below for the recommended IAM policies for the IAM user, and methods for handling the access key credentials.
 
+5. Optionally, configure a deployment environment. {% data reusables.actions.about-environments %}
+
 ## Creating the workflow
 
 Once you've completed the prerequisites, you can proceed with creating the workflow.
@@ -75,6 +77,8 @@ The following example workflow demonstrates how to build a container image and p
 
 Ensure that you provide your own values for all the variables in the `env` key of the workflow.
 
+{% data reusables.actions.delete-env-key %}
+
 ```yaml{:copy}
 {% data reusables.actions.actions-not-certified-by-github-comment %}
 
@@ -94,17 +98,11 @@ env:
   CONTAINER_NAME: MY_CONTAINER_NAME           # set this to the name of the container in the
                                                # containerDefinitions section of your task definition
 
-defaults:
-  run:
-    shell: bash
-
 jobs:
   deploy:
     name: Deploy
-    runs-on: ubuntu-latest{% ifversion fpt or ghes > 3.1 or ghae-next %}
-    permissions:
-      packages: write
-      contents: read{% endif %}
+    runs-on: ubuntu-latest
+    environment: production
 
     {% raw %}steps:
       - name: Checkout
@@ -151,9 +149,10 @@ jobs:
           wait-for-service-stability: true{% endraw %}
 ```
 
-
 ## Additional resources
 
+For the original starter workflow, see [`aws.yml`](https://github.com/actions/starter-workflows/blob/main/deployments/aws.yml) in the {% data variables.product.prodname_actions %} `starter-workflows` repository.
+
 For more information on the services used in these examples, see the following documentation:
 
 * "[Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)" in the Amazon AWS documentation.

content/actions/deployment/deploying-to-azure-app-service.md

@@ -67,13 +67,19 @@ Before creating your {% data variables.product.prodname_actions %} workflow, you
 
    In your {% data variables.product.prodname_dotcom %} repository, create a secret named `AZURE_WEBAPP_PUBLISH_PROFILE` that contains the contents of the publish profile. For more information on creating secrets, see "[Encrypted secrets](/actions/reference/encrypted-secrets#creating-encrypted-secrets-for-a-repository)."
 
+4. For Linux apps, add an app setting called `WEBSITE_WEBDEPLOY_USE_SCM` and set it to true in your app. For more information, see "[Configure apps in the portal](https://docs.microsoft.com/en-us/azure/app-service/configure-common#configure-app-settings)" in the Azure documentation.
+
+5. Optionally, configure a deployment environment. {% data reusables.actions.about-environments %}
+
 ## Creating the workflow
 
 Once you've completed the prerequisites, you can proceed with creating the workflow.
 
-The following example workflow demonstrates how to build, test, and deploy the Node.js project to Azure App Service.
+The following example workflow demonstrates how to build, test, and deploy the Node.js project to Azure App Service when a release is created.
 
-Ensure that you set `AZURE_WEBAPP_NAME` in the workflow `env` key to the name of the web app you created.
+Ensure that you set `AZURE_WEBAPP_NAME` in the workflow `env` key to the name of the web app you created. You can also change `AZURE_WEBAPP_PACKAGE_PATH` if the path to your project is not the repository root and `NODE_VERSION` if you want to use a node version other than `10.x`.
+
+{% data reusables.actions.delete-env-key %}
 
 ```yaml{:copy}
 {% data reusables.actions.actions-not-certified-by-github-comment %}
@@ -91,6 +97,8 @@ jobs:
   build-and-deploy:
     name: Build and Deploy
     runs-on: ubuntu-latest
+    environment: production
+
     steps:
       - uses: actions/checkout@v2
 
@@ -121,4 +129,6 @@ The following resources may also be useful:
 
 * For the original starter workflow, see [`azure.yml`](https://github.com/actions/starter-workflows/blob/main/deployments/azure.yml) in the {% data variables.product.prodname_actions %} `starter-workflows` repository.
 * The action used to deploy the web app is the official Azure [`Azure/webapps-deploy`](https://github.com/Azure/webapps-deploy) action.
+* For more examples of GitHub Action workflows that deploy to Azure, see the 
+[actions-workflow-samples](https://github.com/Azure/actions-workflow-samples) repository.
 * The "[Create a Node.js web app in Azure](https://docs.microsoft.com/en-us/azure/app-service/quickstart-nodejs)" quickstart in the Azure web app documentation demonstrates using VS Code with the [Azure App Service extension](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azureappservice).

content/actions/deployment/deploying-to-google-kubernetes-engine.md

@@ -13,7 +13,7 @@ topics:
   - CD
   - Containers
   - Google Kubernetes Engine
-shortTitle: Deploy to Kubernetes (GKE)
+shortTitle: Deploy to Google Kubernetes Engine
 ---
 
 {% data reusables.actions.enterprise-beta %}
@@ -21,7 +21,7 @@ shortTitle: Deploy to Kubernetes (GKE)
 
 ## Introduction
 
-This guide explains how to use {% data variables.product.prodname_actions %} to build a containerized application, push it to Google Container Registry (GCR), and deploy it to Google Kubernetes Engine (GKE).
+This guide explains how to use {% data variables.product.prodname_actions %} to build a containerized application, push it to Google Container Registry (GCR), and deploy it to Google Kubernetes Engine (GKE) when a release is created.
 
 GKE is a managed Kubernetes cluster service from Google Cloud that can host your containerized workloads in the cloud or in your own datacenter. For more information, see [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine).
 
@@ -60,7 +60,7 @@ $ gcloud services enable \
 
 ### Configuring a service account and storing its credentials
 
-This procedure demonstrates how to create the service account for your GKE integration. It explains how to create the account, add roles to it, retrieve its keys, and store them as a base64-encoded [encrypted repository secret](/actions/reference/encrypted-secrets) named `GKE_SA_KEY`.
+This procedure demonstrates how to create the service account for your GKE integration. It explains how to create the account, add roles to it, retrieve its keys, and store them as a base64-encoded encrypted repository secret named `GKE_SA_KEY`.
 
 1. Create a new service account:
   {% raw %}
@@ -96,16 +96,29 @@ This procedure demonstrates how to create the service account for your GKE integ
   $ export GKE_SA_KEY=$(cat key.json | base64)
   ```
   {% endraw %}
+  For more information about how to store a secret, see "[Encrypted secrets](/actions/security-guides/encrypted-secrets)."
+
+### Storing your project name
+
+Store the name of your project as a secret named `GKE_PROJECT`. For more information about how to store a secret, see "[Encrypted secrets](/actions/security-guides/encrypted-secrets)."
 
 ### (Optional) Configuring kustomize
 Kustomize is an optional tool used for managing YAML specs. After creating a _kustomization_ file, the workflow below can be used to dynamically set fields of the image and pipe in the result to `kubectl`. For more information, see [kustomize usage](https://github.com/kubernetes-sigs/kustomize#usage).
 
+### (Optional) Configure a deployment environment
+
+{% data reusables.actions.about-environments %}
+
 ## Creating the workflow
 
 Once you've completed the prerequisites, you can proceed with creating the workflow.
 
 The following example workflow demonstrates how to build a container image and push it to GCR. It then uses the Kubernetes tools (such as `kubectl` and `kustomize`) to pull the image into the cluster deployment.
 
+Under the `env` key, change the value of `GKE_CLUSTER` to the name of your cluster, `GKE_ZONE` to your cluster zone, `DEPLOYMENT_NAME` to the name of your deployment, and `IMAGE` to the name of your image.
+
+{% data reusables.actions.delete-env-key %}
+
 ```yaml{:copy}
 {% data reusables.actions.actions-not-certified-by-github-comment %}
 
@@ -126,8 +139,9 @@ jobs:
   setup-build-publish-deploy:
     name: Setup, Build, Publish, and Deploy
     runs-on: ubuntu-latest
-    steps:
+    environment: production
 
+    steps:
     - name: Checkout
       uses: actions/checkout@v2
 
@@ -137,7 +151,8 @@ jobs:
         service_account_key: {% raw %}${{ secrets.GKE_SA_KEY }}{% endraw %}
         project_id: {% raw %}${{ secrets.GKE_PROJECT }}{% endraw %}
 
-    # Configure docker to use the gcloud command-line tool as a credential helper
+    # Configure Docker to use the gcloud command-line tool as a credential
+    # helper for authentication
     - run: |-
         gcloud --quiet auth configure-docker
 
@@ -165,7 +180,7 @@ jobs:
     # Set up kustomize
     - name: Set up Kustomize
       run: |-
-        curl --location https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize%2Fv4.2.0/kustomize_v4.2.0_linux_amd64.tar.gz | tar xz
+        curl -sfLo kustomize https://github.com/kubernetes-sigs/kustomize/releases/download/v3.1.0/kustomize_3.1.0_linux_amd64
         chmod u+x ./kustomize
 
     # Deploy the Docker image to the GKE cluster

content/actions/deployment/deploying-with-github-actions.md

@@ -0,0 +1,173 @@
+---
+title: Deploying with GitHub Actions
+intro: Learn how to control deployments with features like environments and concurrency.
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  fpt: '*'
+  ghes: '>=3.1'
+  ghae: '*'
+type: overview
+topics:
+  - CD
+shortTitle: Deploy with GitHub Actions
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+
+## Introduction
+
+{% data variables.product.prodname_actions %} offers features that let you control deployments. You can:
+
+- Trigger workflows with a variety of events.
+- Configure environments to set rules before a job can proceed and to limit access to secrets.
+- Use concurrency to control the number of deployments running at a time.
+
+For more information about continuous deployment, see "[About continuous deployment](/actions/deployment/about-continuous-deployment)."
+
+## Prerequisites
+
+You should be familiar with the syntax for {% data variables.product.prodname_actions %}. For more information, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
+
+## Triggering your deployment
+
+You can use a variety of events to trigger your deployment workflow. Some of the most common are: `pull_request`, `push`, `release`, and `workflow_dispatch`.
+
+For example, a workflow with the following triggers runs whenever:
+
+- There is a push to the `main` branch.
+- A pull request targeting the `main` branch is opened, synchronized, or reopened.
+- A release is created.
+- Someone manually triggers it.
+
+```yaml
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - main
+  release:
+    types:
+      - created
+  workflow_dispatch:
+```
+
+For more information, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows)."
+
+## Using environments
+
+{% data reusables.actions.about-environments %}
+
+## Using concurrency
+
+Concurrency ensures that only a single job or workflow using the same concurrency group will run at a time. You can use concurrency so that an environment has a maximum of one deployment in progress and one deployment pending at a time.
+
+{% note %}
+
+**Note:** `concurrency` and `environment` are not connected. The concurrency value can be any string; it does not need to be an environment name. Additionally, if another workflow uses the same environment but does not specify concurrency, that workflow will not be subject to any concurrency rules.
+
+{% endnote %}
+
+For example, when the following workflow runs, it will be paused with the status `pending` if any job or workflow that uses the `production` concurrency group is in progress. It will also cancel any job or workflow that uses the `production` concurrency group and has the status `pending`. This means that there will be a maximum of one running and one pending job or workflow in that uses the `production` concurrency group.
+
+```yaml
+name: Deployment
+
+concurrency: production
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  deployment:
+    runs-on: ubuntu-latest
+    environment: production
+    steps:
+      - name: deploy
+        # ...deployment-specific steps
+```
+
+You can also specify concurrency at the job level. This will allow other jobs in the workflow to proceed even if the concurrent job is `pending`.
+
+```yaml
+name: Deployment
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  deployment:
+    runs-on: ubuntu-latest
+    environment: production
+    concurrency: production
+    steps:
+      - name: deploy
+        # ...deployment-specific steps
+```
+
+You can also use `cancel-in-progress` to cancel any currently running job or workflow in the same concurrency group.
+
+```yaml
+name: Deployment
+
+concurrency: 
+  group: production
+  cancel-in-progress: true
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  deployment:
+    runs-on: ubuntu-latest
+    environment: production
+    steps:
+      - name: deploy
+        # ...deployment-specific steps
+```
+
+## Viewing deployment history
+
+When a {% data variables.product.prodname_actions %} workflow deploys to an environment, the environment is displayed on the main page of the repository. For more information about viewing deployments to environments, see "[Viewing deployment history](/developers/overview/viewing-deployment-history)."
+
+## Monitoring workflow runs
+
+Every workflow run generates a real-time graph that illustrates the run progress. You can use this graph to monitor and debug deployments. For more information see, "[Using the visualization graph](/actions/monitoring-and-troubleshooting-workflows/using-the-visualization-graph)."
+
+You can also view the logs of each workflow run and the history of workflow runs. For more information, see "[Viewing workflow run history](/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history)."
+
+## Tracking deployments through apps
+
+{% ifversion fpt %}
+If your {% data variables.product.product_name %} personal account or organization is integrated with Microsoft Teams or Slack, you can track deployments that use environments through Microsoft Teams or Slack. For example, you can receive notifications through the app when a deployment is pending approval, when a deployment is approved, or when the deployment status changes. For more information about integrating  Microsoft Teams or Slack, see "[GitHub extensions and integrations](/github/customizing-your-github-workflow/exploring-integrations/github-extensions-and-integrations#team-communication-tools)."
+{% endif %}
+
+You can also build an app that uses deployment and deployment status webhooks to track deployments. {% data reusables.actions.environment-deployment-event %} For more information, see "[Apps](/developers/apps)" and "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment)."
+
+{% ifversion fpt or ghes %}
+
+## Choosing a runner
+
+You can run your deployment workflow on {% data variables.product.product_name %}-hosted runners or on self-hosted runners. Traffic from {% data variables.product.product_name %}-hosted runners can come from a [wide range of network addresses](/rest/reference/meta#get-github-meta-information). If you are deploying to an internal environment and your company restricts external traffic into private networks, {% data variables.product.prodname_actions %} workflows running on {% data variables.product.product_name %}-hosted runners may not be communicate with your internal services or resources. To overcome this, you can host your own runners. For more information, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners)" and "[About GitHub-hosted runners](/actions/using-github-hosted-runners/about-github-hosted-runners)."
+
+{% endif %}
+
+## Displaying a status badge
+
+You can use a status badge to display the status of your deployment workflow. {% data reusables.repositories.actions-workflow-status-badge-intro %}
+
+For more information, see "[Adding a workflow status badge](/actions/managing-workflow-runs/adding-a-workflow-status-badge)."
+
+## Next steps
+
+This article demonstrated features of {% data variables.product.prodname_actions %} that you can add to your deployment workflows.
+
+{% data reusables.actions.cd-templates-actions %}

content/actions/deployment/index.md

@@ -7,10 +7,13 @@ versions:
   ghes: '*'
   ghae: '*'
 children:
+  - /about-continuous-deployment
+  - /deploying-with-github-actions
+  - /using-environments-for-deployment
+  - /viewing-deployment-history
   - /deploying-to-amazon-elastic-container-service
   - /deploying-to-azure-app-service
   - /deploying-to-google-kubernetes-engine
   - /installing-an-apple-certificate-on-macos-runners-for-xcode-development
-  - /environments
 ---
 

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

@@ -1,9 +1,12 @@
 ---
-title: Environments
-intro: You can configure environments with protection rules and secrets. A workflow job can reference an environment to use the environment's protection rules and secrets.
+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.
 product: '{% data reusables.gated-features.environments %}'
+miniTocMaxHeadingLevel: 3
 redirect_from:
   - /actions/reference/environments
+  - /actions/deployment/environments
 versions:
   fpt: '*'
   ghes: '>=3.1'
@@ -13,30 +16,34 @@ versions:
 
 ## About environments
 
+Environments are used to describe a general deployment target like `production`, `staging`, or `development`. When a {% data variables.product.prodname_actions %} workflow deploys to an environment, the environment is displayed on the main page of the repository. For more information about viewing deployments to environments, see "[Viewing deployment history](/developers/overview/viewing-deployment-history)."
+
 You can configure environments with protection rules and secrets. When a workflow job references an environment, the job won't start until all of the environment's protection rules pass. A job also cannot access secrets that are defined in an environment until all the environment protection rules pass.
 
 {% ifversion fpt %}
-Environment protection rules and environment secrets are only available on private repositories with {% data variables.product.prodname_ghe_cloud %}. {% data reusables.enterprise.link-to-ghec-trial %}
+{% note %}
 
-If you don't use {% data variables.product.prodname_ghe_cloud %} and convert a repository from public to private, any configured protection rules or environment secrets will be ignored, and you will not be able to configure any environments. If you convert your repository back to public, you will have access to any previously configured protection rules and environment secrets.
+**Note:** If you don't use {% data variables.product.prodname_ghe_cloud %} and convert a repository from public to private, any configured protection rules or environment secrets will be ignored, and you will not be able to configure any environments. If you convert your repository back to public, you will have access to any previously configured protection rules and environment secrets. {% data reusables.enterprise.link-to-ghec-trial %}
+
+{% endnote %}
 {% endif %}
 
-### Environment protection rules
+## Environment protection rules
 
 Environment protection rules require specific conditions to pass before a job referencing the environment can proceed. {% ifversion fpt or ghae-next or ghes > 3.1 %}You can use environment protection rules to require a manual approval, delay a job, or restrict the environment to certain branches.{% else %}You can use environment protection rules to require a manual approval or delay a job.{% endif %}
 
-#### Required reviewers
+### Required reviewers
 
 Use required reviewers to require a specific person or team to approve workflow jobs that reference the environment. You can list up to six users or teams as reviewers. The reviewers must have at least read access to the repository. Only one of the required reviewers needs to approve the job for it to proceed.
 
 For more information on reviewing jobs that reference an environment with required reviewers, see "[Reviewing deployments](/actions/managing-workflow-runs/reviewing-deployments)."
 
-#### Wait timer
+### Wait timer
 
 Use a wait timer to delay a job for a specific amount of time after the job is initially triggered. The time (in minutes) must be an integer between 0 and 43,200 (30 days).
 
 {% ifversion fpt or ghae-next or ghes > 3.1 %}
-#### Deployment branches
+### Deployment branches
 
 Use deployment branches to restrict which branches can deploy to the environment. Below are the options for deployment branches for an environment:
 
@@ -46,13 +53,13 @@ Use deployment branches to restrict which branches can deploy to the environment
 
   For example, if you specify `releases/*` as a deployment branch rule, only branches whose name begins with `releases/` can deploy to the environment. (Wildcard characters will not match `/`. To match branches that begin with `release/` and contain an additional single slash, use `release/*/*`.) If you add `main` as a deployment branch rule, a branch named `main` can also deploy to the environment. For more information about syntax options for deployment branches, see the [Ruby File.fnmatch documentation](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch).
 {% endif %}
-### Environment secrets
+## Environment secrets
 
 Secrets stored in an environment are only available to workflow jobs that reference the environment. If the environment requires approval, a job cannot access environment secrets until one of the required reviewers approves it. For more information about secrets, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
 
 {% note %}
 
-**Note:** Workflows that run on self-hosted runners are not run in an isolated container, even if they use environments. Environment secrets should be treated with the same level as security as repository and organization secrets. For more information, see "[Security hardening for GitHub Actions](/actions/learn-github-actions/security-hardening-for-github-actions#hardening-for-self-hosted-runners)."
+**Note:** Workflows that run on self-hosted runners are not run in an isolated container, even if they use environments. Environment secrets should be treated with the same level of security as repository and organization secrets. For more information, see "[Security hardening for GitHub Actions](/actions/learn-github-actions/security-hardening-for-github-actions#hardening-for-self-hosted-runners)."
 
 {% endnote %}
 
@@ -63,25 +70,36 @@ Secrets stored in an environment are only available to workflow jobs that refere
 {% data reusables.repositories.navigate-to-repo %}
 {% data reusables.repositories.sidebar-settings %}
 {% data reusables.github-actions.sidebar-environment %}
-1. Click **New environment**.
-1. Enter a name for the environment, then click **Configure environment**. Environment names are not case sensitive. An environment name may not exceed 255 characters and must be unique within the repository.
-1. Configure any environment protection rules or environment secrets.
+{% data reusables.github-actions.new-environment %}
+{% data reusables.github-actions.name-environment %}
+1. Optionally, specify people or teams that must approve workflow jobs that use this environment.
+   1. Select **Required reviewers**.
+   1. Enter up to 6 people or teams. Only one of the required reviewers needs to approve the job for it to proceed.
+   1. Click **Save protection rules**.
+2. Optionally, specify the amount of time to wait before allowing workflow jobs that use this environment to proceed.
+   1. Select **Wait timer**.
+   1. Enter the number of minutes to wait.
+   1. Click **Save protection rules**.
+3. Optionally, specify what branches can deploy to this environment. For more information about the possible values, see "[Deployment branches](#deployment-branches)."
+   1. Select the desired option in the **Deployment branches** dropdown.
+   1. If you chose **Selected branches**, enter the branch name patterns that you want to allow.
+4. Optionally, add environment secrets. These secrets are only available to workflow jobs that use the environment. Additionally, workflow jobs that use this environment can only access these secrets after any configured rules (for example, required reviewers) pass. For more information about secrets, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
+   1. Under **Environment secrets**, click **Add Secret**.
+   1. Enter the secret name.
+   1. Enter the secret value.
+   1. Click **Add secret**.
 
 {% ifversion fpt or ghae-next or ghes > 3.1 %}You can also create and configure environments through the REST API. For more information, see "[Environments](/rest/reference/repos#environments)" and "[Secrets](/rest/reference/actions#secrets)."{% endif %}
 
 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.
 
-## Referencing an 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. When the job is sent to the runner, the job can access the environment's secrets.
-
-For more information on syntax to reference environments in workflows, see "[Workflow syntax for GitHub Actions](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idenvironment)." For more information on reviewing jobs that reference an environment with required reviewers, see "[Reviewing deployments](/actions/managing-workflow-runs/reviewing-deployments)."
+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 "[Viewing deployment history](/developers/overview/viewing-deployment-history)."
 
-{% ifversion fpt or ghae-next or ghes > 3.1 %}
-## Using concurrency to serialize deployments in an environment
-You can use concurrency so that an environment has a maximum of one deployment in progress and one deployment pending at a time. For more information, see "[Workflow syntax for GitHub Actions](/actions/reference/workflow-syntax-for-github-actions#concurrency)."{% endif %}
+{% data reusables.actions.environment-example %}
 
 ## Deleting an environment
 
@@ -96,3 +114,13 @@ Deleting an environment will delete all secrets and protection rules associated
 2. Click **I understand, delete this environment**.
 
 {% ifversion fpt or ghae-next or ghes > 3.1 %}You can also delete environments through the REST API. For more information, see "[Environments](/rest/reference/repos#environments)."{% endif %}
+
+## How environments relate to deployments
+
+{% data reusables.actions.environment-deployment-event %}
+
+You can access these objects through the REST API or GraphQL API. You can also subscribe to these webhook events. For more information, see "[Repositories](/rest/reference/repos#deployments)" (REST API), "[Objects](/graphql/reference/objects#deployment)" (GraphQL API), or "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment)."
+
+## Next steps
+
+{% data variables.product.prodname_actions %} provides several features for managing your deployments. For more information, see "[Deploying with GitHub Actions](/actions/deployment/deploying-with-github-actions)."

content/actions/deployment/viewing-deployment-history.md

@@ -8,17 +8,19 @@ versions:
 topics:
   - API
 shortTitle: View deployment history
+redirect_from:
+  - /developers/overview/viewing-deployment-history
 ---
 
 
-You can deliver deployments through {% ifversion fpt or ghes > 3.0 %}{% data variables.product.prodname_actions %} and environments or with {% endif %}the REST API and third party apps. {% ifversion fpt or ghes > 3.0 %}For more information about {% data variables.product.prodname_actions %}, see "[{% data variables.product.prodname_actions %}](/actions)." {% endif %}For more information about deployments with the REST API, see "[Repositories](/rest/reference/repos#deployments)."
+You can deliver deployments through {% ifversion fpt or ghae or ghes > 3.0 %}{% data variables.product.prodname_actions %} and environments or with {% endif %}the REST API and third party apps. {% ifversion fpt or ghae ghes > 3.0 %}For more information about using environments to deploy with {% data variables.product.prodname_actions %}, see "[Using environments for deployment](/actions/deployment/using-environments-for-deployment)." {% endif %}For more information about deployments with the REST API, see "[Repositories](/rest/reference/repos#deployments)."
 
 To view current and past deployments, click **Environments** on the home page of your repository.
 {% ifversion ghae or ghes < 3.0 %}
 ![Environments](/assets/images/enterprise/2.22/environments-sidebar.png){% else %}
 ![Environments](/assets/images/environments-sidebar.png){% endif %}
 
-The deployments page displays the last active deployment of each environment for your repository. If the deployment includes an environment URL, a "View deployment" button that links to the URL is shown next to the deployment.
+The deployments page displays the last active deployment of each environment for your repository. If the deployment includes an environment URL, a **View deployment** button that links to the URL is shown next to the deployment.
 
 The activity log shows the deployment history for your environments. By default, only the most recent deployment for an environment has an `Active` status; all previously active deployments have an `Inactive` status. For more information on automatic inactivation of deployments, see "[Inactive deployments](/rest/reference/repos#inactive-deployments)."
 

content/actions/index.md

@@ -9,6 +9,7 @@ featuredLinks:
   guides:
     - /actions/learn-github-actions
     - /actions/guides/about-continuous-integration
+    - /actions/deployment/deploying-with-github-actions
     - /actions/guides/about-packaging-with-github-actions
     - /actions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting
   guideCards:

content/actions/learn-github-actions/creating-workflow-templates.md

@@ -23,7 +23,7 @@ topics:
 
 ## Creating a workflow template
 
-Workflow templates can be created by users with write access to the organization's `.github` repository. The templates can then be used by organization members who have permission to create workflows.
+Workflow templates can be created by users with write access to the organization's `.github` repository. The templates can then be used by organization members who have permission to create workflows. You can share workflow templates if your organization's repository is public or if the repository is private and on an Enterprise plan.
 
 {% ifversion fpt or ghes > 3.3 or ghae-issue-4757 %}
 {% note %}

content/actions/learn-github-actions/managing-complex-workflows.md

@@ -175,7 +175,7 @@ To learn more about {% data variables.product.prodname_dotcom %}-hosted runner l
 
 ## Using environments
 
-You can configure environments with protection rules and secrets. 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 "[Environments](/actions/reference/environments)."
+You can configure environments with protection rules and secrets. 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 "[Using environments for deployment](/actions/deployment/using-environments-for-deployment)."
 {% endif %}
 
 ## Using a workflow template

content/actions/learn-github-actions/using-workflow-templates.md

@@ -1,7 +1,7 @@
 ---
 title: Using workflow templates
 shortTitle: Using templates
-intro: You can set up CI using a workflow template that matches the language and tooling you want to use.
+intro: '{% data variables.product.product_name %} provides workflow templates for a variety of languages and tooling.'
 product: '{% data reusables.gated-features.actions %}'
 redirect_from:
   - /articles/setting-up-continuous-integration-using-github-actions
@@ -17,39 +17,37 @@ type: tutorial
 topics:
   - Workflows
   - CI
+  - CD
 ---
 
 {% data reusables.actions.enterprise-beta %}
 {% data reusables.actions.enterprise-github-hosted-runners %}
 
-Anyone with write permission to a repository can set up continuous integration (CI) using {% data variables.product.prodname_actions %}. 
+## About workflow templates
 
-You can use workflow templates to create new workflows in an organization's public repository. To use templates to create workflows in private repositories, the organization must be part of an enterprise plan.
+{% data variables.product.product_name %} offers workflow templates for a variety of languages and tooling. When you set up workflows in your repository, {% data variables.product.product_name %} analyzes the code in your repository and recommends workflows based on the language and framework in your repository. For example, if you use [Node.js](https://nodejs.org/en/), {% data variables.product.product_name %} will suggest a template file that installs your Node.js packages and runs your tests.
 
-After you set up CI, you can customize the workflow to meet your needs.
+You can also create your own workflow templates to share with your organization. For more information, see "[Creating workflow templates](/actions/learn-github-actions/creating-workflow-templates)."
+
+## Using workflow templates
+
+Anyone with write permission to a repository can set up {% data variables.product.prodname_actions %} workflows for CI/CD or other automation.
 
 {% data reusables.repositories.navigate-to-repo %}
 {% data reusables.repositories.actions-tab %}
-1. If your repository already has existing workflows: In the upper-left corner, click **New workflow**.
-  ![Create a new workflow](/assets/images/help/repository/actions-new-workflow.png)
-2. Find the template that matches the language and tooling you want to use, then click **Set up this workflow**.
-  ![Setup workflow button](/assets/images/help/repository/setup-workflow-button.png)
+1. If you already have a workflow in your repository, click **New workflow**.
+1. Find the template that you want to use, then click **Set up this workflow**.
+1. If the workflow template contains comments detailing additional setup steps, follow these steps.
+1. Some workflow templates use secrets. For example, {% raw %}`${{ secrets.npm_token }}`{% endraw %}. If the workflow template uses a secret, store the value described in the secret name as a secret in your repository. For more information, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
+1. Optionally, make additional changes. For example, you might want to change the value of `on` to change when the workflow runs.
 1. Click **Start commit**.
-  ![Start commit button](/assets/images/help/repository/start-commit.png)
-{% data reusables.files.write_commit_message %}
-{% data reusables.files.choose_commit_branch %}
-{% data reusables.files.propose_new_file %}
-
-Once a push is made to your repository, you can follow the status and detailed logs of your continuous integration workflow run on {% data variables.product.prodname_dotcom %} and receive customized notifications. For more information, see "[Configuring notifications](/github/managing-subscriptions-and-notifications-on-github/configuring-notifications#github-actions-notification-options)" and "[Managing a workflow run](/articles/managing-a-workflow-run)."
-
-{% data reusables.repositories.actions-workflow-status-badge-intro %}
-
-For more information, see "[Adding a workflow status badge](/actions/managing-workflow-runs/adding-a-workflow-status-badge)."
+1. Write a commit message and decide whether to commit directly to the default branch or to open a pull request.
 
 ## Further reading
 
 - "[About continuous integration](/articles/about-continuous-integration)"
-- "[Managing a workflow run](/articles/managing-a-workflow-run)"
+- "[Managing workflow runs](/actions/managing-workflow-runs)"
+- "[About monitoring and troubleshooting](/actions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting)"
 - "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
 {% ifversion fpt %}
 - "[Managing billing for {% data variables.product.prodname_actions %}](/billing/managing-billing-for-github-actions)"

content/actions/learn-github-actions/workflow-syntax-for-github-actions.md

@@ -353,8 +353,6 @@ defaults:
 {% ifversion fpt or ghae-next or ghes > 3.1 %}
 ## `concurrency`
 
-{% data reusables.actions.concurrency-beta %}
-
 Concurrency ensures that only a single job or workflow using the same concurrency group will run at a time. A concurrency group can be any string or expression. The expression can only use the [`github` context](/actions/learn-github-actions/contexts#github-context). For more information about expressions, see "[Expressions](/actions/learn-github-actions/expressions)."
 
 You can also specify `concurrency` at the job level. For more information, see [`jobs.<job_id>.concurrency`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idconcurrency).
@@ -509,7 +507,7 @@ jobs:
 {% ifversion fpt or ghes > 3.0 or ghae %}
 ## `jobs.<job_id>.environment`
 
-The environment that the job references. All environment protection rules must pass before a job referencing the environment is sent to a runner. For more information, see "[Environments](/actions/reference/environments)."
+The environment that the job references. All environment protection rules must pass before a job referencing the environment is sent to a runner. For more information, see "[Using environments for deployment](/actions/deployment/using-environments-for-deployment)."
 
 You can provide the environment as only the environment `name`, or as an environment object with the `name` and `url`. The URL maps to `environment_url` in the deployments API. For more information about the deployments API, see "[Deployments](/rest/reference/repos#deployments)."
 
@@ -544,8 +542,6 @@ environment:
 {% ifversion fpt or ghae-next or ghes > 3.1 %}
 ## `jobs.<job_id>.concurrency`
 
-{% data reusables.actions.concurrency-beta %}
-
 {% note %}
 
 **Note:** When concurrency is specified at the job level, order is not guaranteed for jobs or runs that queue within 5 minutes of each other.

content/actions/managing-workflow-runs/index.md

@@ -19,6 +19,7 @@ children:
   - /approving-workflow-runs-from-public-forks
   - /reviewing-deployments
   - /disabling-and-enabling-a-workflow
+  - /skipping-workflow-runs
   - /deleting-a-workflow-run
   - /downloading-workflow-artifacts
   - /removing-workflow-artifacts

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

@@ -13,7 +13,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, the workflow run will be automatically canceled.
 
-For more information about environments and required approvals, see "[Environments](/actions/reference/environments)."{% ifversion fpt or ghae-next or ghes > 3.1 %} For information about how to review deployments with the REST API, see "[Workflow Runs](/rest/reference/actions#workflow-runs)."{% endif %}
+For more information about environments and required approvals, see "[Using environments for deployment](/actions/deployment/using-environments-for-deployment)."{% ifversion fpt or ghae-next or ghes > 3.1 %} For information about how to review deployments with the REST API, see "[Workflow Runs](/rest/reference/actions#workflow-runs)."{% endif %}
 
 ## Approving or rejecting a job
 

content/actions/managing-workflow-runs/skipping-workflow-runs.md

@@ -0,0 +1,33 @@
+---
+title: Skipping workflow runs
+intro: 'You can skip workflow runs triggered by the `push` and `pull_request` events by including a command in your commit message.'
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  fpt: '*'
+  ghes: '>=3.0'
+  ghae: 'ghae-next'
+shortTitle: Skip workflow runs
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+
+Workflows that would otherwise be triggered using `on: push` or `on: pull_request` won't be triggered if you add any of the following strings to the commit message in a push, or the HEAD commit of a pull request:
+
+* `[skip ci]`
+* `[ci skip]`
+* `[no ci]`
+* `[skip actions]`
+* `[actions skip]`
+
+Alternatively, you can end the commit message with two empty lines followed by either `skip-checks: true` or `skip-checks:true`.
+
+You won't be able to merge the pull request if your repository is configured to require specific checks to pass first. To allow the pull request to be merged you can push a new commit to the pull request without the skip instruction in the commit message.
+
+{% note %}
+
+**Note:** Skip instructions only apply to the `push` and `pull_request` events. For example, adding `[skip ci]` to a commit message won't stop a workflow that's triggered `on: pull_request_target` from running.
+
+{% endnote %}
+
+Skip instructions only apply to the workflow run(s) that would be triggered by the commit that contains the skip instructions. You can also disable a workflow from running. For more information, see "[Disabling and enabling a workflow](/actions/managing-workflow-runs/disabling-and-enabling-a-workflow)."

content/actions/monitoring-and-troubleshooting-workflows/index.md

@@ -17,6 +17,7 @@ children:
   - /viewing-job-execution-time
   - /using-workflow-run-logs
   - /enabling-debug-logging
+  - /notifications-for-workflow-runs
 ---
 {% data reusables.actions.enterprise-beta %}
 {% data reusables.actions.enterprise-github-hosted-runners %}

content/actions/monitoring-and-troubleshooting-workflows/notifications-for-workflow-runs.md

@@ -0,0 +1,15 @@
+---
+title: Notifications for workflow runs
+intro: 'You can subscribe to notifications about workflow runs that you trigger.'
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  fpt: '*'
+  ghes: '*'
+  ghae: '*'
+shortTitle: Notifications
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+
+{% data reusables.repositories.workflow-notifications %}

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

@@ -47,7 +47,7 @@ To help prevent accidental disclosure, {% data variables.product.product_name %}
     - Rotate secrets periodically to reduce the window of time during which a compromised secret is valid.
 {% ifversion fpt or ghes > 3.0 or ghae %}
 - **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 "[Encrypted secrets](/actions/reference/encrypted-secrets)" and "[Environments](/actions/reference/environments)."
+    - 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 "[Encrypted secrets](/actions/reference/encrypted-secrets)" and "[Using environments for deployment](/actions/deployment/using-environments-for-deployment)."
 {% endif %}
 
 ## Using `CODEOWNERS` to monitor changes

content/developers/overview/index.md

@@ -8,7 +8,6 @@ versions:
 children:
   - /about-githubs-apis
   - /managing-deploy-keys
-  - /viewing-deployment-history
   - /using-ssh-agent-forwarding
   - /secret-scanning-partner-program
   - /replacing-github-services

content/rest/reference/repos.md

@@ -178,7 +178,7 @@ You can communicate that a transient environment no longer exists by setting its
 {% ifversion fpt or ghes > 3.1 or ghae-next %}
 ## Environments
 
-The Environments API allows you to create, configure, and delete environments. For more information about environments, see "[Environments](/actions/reference/environments)." To manage environment secrets, see "[Secrets](/rest/reference/actions#secrets)."
+The Environments API allows you to create, configure, and delete environments. For more information about environments, see "[Using environments for deployment](/actions/deployment/using-environments-for-deployment)." To manage environment secrets, see "[Secrets](/rest/reference/actions#secrets)."
 
 {% for operation in currentRestOperations %}
   {% if operation.subcategory == 'environments' %}{% include rest_operation %}{% endif %}

data/reusables/actions/about-environments.md

@@ -0,0 +1 @@
+Environments are used to describe a general deployment target like `production`, `staging`, or `development`. When a {% data variables.product.prodname_actions %} workflow deploys to an environment, the environment is displayed on the main page of the repository. You can use environments to require approval for a job to proceed, restrict which branches can trigger a workflow, or limit access to secrets. For more information about creating environments, see "[Using environments for deployment](/actions/deployment/using-environments-for-deployment)."

data/reusables/actions/cd-templates-actions.md

@@ -0,0 +1,3 @@
+{% data variables.product.product_name %} offers CD workflow templates for several popular services, such as Azure Web App. To learn how to get started using a workflow template, see "[Using workflow templates](/actions/learn-github-actions/using-workflow-templates)" or [browse the full list of deployment workflow templates](https://github.com/actions/starter-workflows/tree/main/deployments). You can also check out our more detailed guides for specific deployment workflows, such as "[Deploying to Azure App Service](/actions/deployment/deploying-to-azure-app-service)."
+
+Many service providers also offer actions on {% data variables.product.prodname_marketplace %} for deploying to their service. For the full list, see [{% data variables.product.prodname_marketplace %}](https://github.com/marketplace?category=deployment&type=actions).

data/reusables/actions/concurrency-beta.md

@@ -1,5 +0,0 @@
-{% note %}
-
-**Note:** Concurrency is currently in beta and subject to change.
-
-{% endnote %}

data/reusables/actions/delete-env-key.md

@@ -0,0 +1 @@
+If you configured a deployment environment, change the value of `environment` to be the name of your environment. If you did not configure an environment{% ifversion fpt %} or if your workflow is in a private repository and you do not use {% data variables.product.prodname_ghe_cloud %}{% endif %}, delete the `environment` key.

data/reusables/actions/environment-deployment-event.md

@@ -0,0 +1 @@
+When a workflow job that references an environment runs, it creates a deployment object with the `environment` property set to the name of your environment. As the workflow progresses, it also creates deployment status objects with the `environment` property set to the name of your environment, the `environment_url` property set to the URL for environment (if specified in the workflow), and the `state` property set to the status of the job.

data/reusables/actions/environment-example.md

@@ -0,0 +1,45 @@
+You can specify an environment for each job in your workflow. To do so, add a `jobs.<job_id>.environment` key followed by the name of the environment.
+
+For example, this workflow will use an environment called `production`.
+
+```yaml
+name: Deployment
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  deployment:
+    runs-on: ubuntu-latest
+    environment: production
+    steps:
+      - name: deploy
+        # ...deployment-specific steps
+```
+
+When the above workflow runs, the `deployment` job will be subject to any rules configured for the `production` environment. For example, if the environment requires reviewers, the job will pause until one of the reviewers approves the job.
+
+You can also specify a URL for the environment. The specified URL will appear on the deployments page for the repository (accessed by clicking **Environments** on the home page of your repository) and in the visualization graph for the workflow run. If a pull request triggered the workflow, the URL is also displayed as a **View deployment** button in the pull request timeline.
+
+```yaml
+name: Deployment
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  deployment:
+    runs-on: ubuntu-latest
+    environment: 
+      name: production
+      url: https://github.com
+    steps:
+      - name: deploy
+        # ...deployment-specific steps
+```
+
+![Workflow graph with URL](/assets/images/help/images/deploy-graph.png)

data/reusables/github-actions/name-environment.md

@@ -0,0 +1 @@
+1. Enter a name for the environment, then click **Configure environment**. Environment names are not case sensitive. An environment name may not exceed 255 characters and must be unique within the repository.

data/reusables/github-actions/new-environment.md

@@ -0,0 +1 @@
+1. Click **New environment**.

data/reusables/repositories/workflow-notifications.md

@@ -1,4 +1,4 @@
-If you enable email or web notifications for {% data variables.product.prodname_actions %}, you'll receive a notification when any workflow runs that you've triggered have completed. The notification will include the workflow run's status (including successful, failed, neutral, and canceled runs). You can also choose to receive a notification only when a workflow run has failed.
+If you enable email or web notifications for {% data variables.product.prodname_actions %}, you'll receive a notification when any workflow runs that you've triggered have completed. The notification will include the workflow run's status (including successful, failed, neutral, and canceled runs). You can also choose to receive a notification only when a workflow run has failed. For more information about enabling or disabling notifications, see "[About notifications](/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/about-notifications)."
 
 Notifications for scheduled workflows are sent to the user who initially created the workflow. If a different user updates the cron syntax in the workflow file, subsequent notifications will be sent to that user instead.{% ifversion fpt or ghes > 2.22 %} If a scheduled workflow is disabled and then re-enabled, notifications will be sent to the user who re-enabled the workflow rather than the user who last modified the cron syntax.{% endif %}