diff --git a/content/actions/concepts/use-cases/deploying-with-github-actions.md b/content/actions/concepts/use-cases/deploying-with-github-actions.md index 4f7b0b5abada..a2952db9a68e 100644 --- a/content/actions/concepts/use-cases/deploying-with-github-actions.md +++ b/content/actions/concepts/use-cases/deploying-with-github-actions.md @@ -59,6 +59,8 @@ For more information, see [AUTOTITLE](/actions/using-workflows/events-that-trigg {% data reusables.actions.about-environments %} +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 deployment protection rules pass. To learn more, see [Using custom deployment protection rules](#using-custom-deployment-protection-rules) in this article. + ## 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. For more information about concurrency, see [AUTOTITLE](/actions/using-jobs/using-concurrency). @@ -142,6 +144,30 @@ Every workflow run generates a real-time graph that illustrates the run progress You can also view the logs of each workflow run and the history of workflow runs. For more information, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history). +## Using required reviews in workflows + +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/managing-environments-for-deployment). For information about how to review deployments with the REST API, see [AUTOTITLE](/rest/actions/workflow-runs). + +## Using custom deployment protection rules + +{% data reusables.actions.custom-deployment-protection-rules-beta-note %} + +{% data reusables.actions.about-custom-deployment-protection-rules %} + +Custom deployment protection rules are powered by {% data variables.product.prodname_github_apps %} and run based on webhooks and callbacks. Approval or rejection of a workflow job is based on consumption of the `deployment_protection_rule` webhook. For more information, see [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment_protection_rule) and [Approving or rejecting deployments](/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/creating-custom-deployment-protection-rules#approving-or-rejecting-deployments). + +Once you have created a custom deployment protection rule and installed it on your repository, the custom deployment protection rule will automatically be available for all environments in the repository. + +Deployments to an environment can be approved or rejected based on the conditions defined in any external service like an approved ticket in an IT Service Management (ITSM) system, vulnerable scan result on dependencies, or stable health metrics of a cloud resource. The decision to approve or reject deployments is at the discretion of the integrating third-party application and the gating conditions you define in them. The following are a few use cases for which you can create a deployment protection rule. + +* ITSM & Security Operations: you can check for service readiness by validating quality, security, and compliance processes that verify deployment readiness. +* Observability systems: you can consult monitoring or observability systems (Asset Performance Management Systems and logging aggregators, cloud resource health verification systems, etc.) for verifying the safety and deployment readiness. +* Code quality & testing tools: you can check for automated tests on CI builds which need to be deployed to an environment. + +Alternatively, you can write your own protection rules for any of the above use cases or you can define any custom logic to safely approve or reject deployments from pre-production to production environments. + ## Tracking deployments through apps {% ifversion fpt or ghec %} diff --git a/content/actions/concepts/use-cases/using-github-actions-for-project-management.md b/content/actions/concepts/use-cases/using-github-actions-for-project-management.md index a001e077166d..070c9a9b7a07 100644 --- a/content/actions/concepts/use-cases/using-github-actions-for-project-management.md +++ b/content/actions/concepts/use-cases/using-github-actions-for-project-management.md @@ -35,9 +35,7 @@ Workflows can do many things, such as commenting on an issue, adding or removing You can learn about using {% data variables.product.prodname_actions %} for project management by following these tutorials, which include example workflows that you can adapt to meet your needs. -* [AUTOTITLE](/actions/managing-issues-and-pull-requests/adding-labels-to-issues){%- ifversion projects-v1 %} -* [AUTOTITLE](/actions/managing-issues-and-pull-requests/removing-a-label-when-a-card-is-added-to-a-project-board-column) -* [AUTOTITLE](/actions/managing-issues-and-pull-requests/moving-assigned-issues-on-project-boards){% endif %} +* [AUTOTITLE](/actions/managing-issues-and-pull-requests/adding-labels-to-issues) * [AUTOTITLE](/actions/managing-issues-and-pull-requests/commenting-on-an-issue-when-a-label-is-added) * [AUTOTITLE](/actions/managing-issues-and-pull-requests/closing-inactive-issues) * [AUTOTITLE](/actions/managing-issues-and-pull-requests/scheduling-issue-creation) diff --git a/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/creating-custom-deployment-protection-rules.md b/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/creating-custom-deployment-protection-rules.md index c10dac38a53b..024365225de6 100644 --- a/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/creating-custom-deployment-protection-rules.md +++ b/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/creating-custom-deployment-protection-rules.md @@ -16,25 +16,11 @@ redirect_from: - /actions/managing-workflow-runs-and-deployments/managing-deployments/creating-custom-deployment-protection-rules --- -{% data reusables.actions.custom-deployment-protection-rules-beta-note %} - -## About custom deployment protection rules - -{% data reusables.actions.about-custom-deployment-protection-rules %} - -Custom deployment protection rules are powered by {% data variables.product.prodname_github_apps %} and run based on webhooks and callbacks. Approval or rejection of a workflow job is based on consumption of the `deployment_protection_rule` webhook. For more information, see [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment_protection_rule) and [Approving or rejecting deployments](#approving-or-rejecting-deployments). +## Prerequisites -Once you have created a custom deployment protection rule and installed it on your repository, the custom deployment protection rule will automatically be available for all environments in the repository. - -## Using custom deployment protection rules to approve or reject deployments - -Deployments to an environment can be approved or rejected based on the conditions defined in any external service like an approved ticket in an IT Service Management (ITSM) system, vulnerable scan result on dependencies, or stable health metrics of a cloud resource. The decision to approve or reject deployments is at the discretion of the integrating third-party application and the gating conditions you define in them. The following are a few use cases for which you can create a deployment protection rule. - -* ITSM & Security Operations: you can check for service readiness by validating quality, security, and compliance processes that verify deployment readiness. -* Observability systems: you can consult monitoring or observability systems (Asset Performance Management Systems and logging aggregators, cloud resource health verification systems, etc.) for verifying the safety and deployment readiness. -* Code quality & testing tools: you can check for automated tests on CI builds which need to be deployed to an environment. +{% data reusables.actions.custom-deployment-protection-rules-beta-note %} -Alternatively, you can write your own protection rules for any of the above use cases or you can define any custom logic to safely approve or reject deployments from pre-production to production environments. +For general information about deployment protection rules, see [AUTOTITLE](/actions/concepts/use-cases/deploying-with-github-actions#using-custom-deployment-protection-rules). ## Creating a custom deployment protection rule with {% data variables.product.prodname_github_apps %} diff --git a/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment.md b/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment.md index d948f9f7993c..3d554c897ea0 100644 --- a/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment.md +++ b/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment.md @@ -23,14 +23,7 @@ versions: ghec: '*' --- - -## 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 [AUTOTITLE](/actions/deployment/managing-your-deployments/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 deployment protection rules pass. - -Optionally, you can bypass an environment's protection rules and force all pending jobs referencing the environment to proceed. For more information, see [AUTOTITLE](/actions/managing-workflow-runs/reviewing-deployments#bypassing-environment-protection-rules). +## Prerequisites {% ifversion fpt %} @@ -41,117 +34,8 @@ Optionally, you can bypass an environment's protection rules and force all pendi {% endif %} -## Deployment protection rules - -Deployment protection rules require specific conditions to pass before a job referencing the environment can proceed. You can use deployment protection rules to require a manual approval, delay a job, or restrict the environment to certain branches. You can also create and implement custom protection rules powered by {% data variables.product.prodname_github_apps %} to use third-party systems to control deployments referencing environments configured on {% data variables.product.github %}. - -Third-party systems can be observability systems, change management systems, code quality systems, or other manual configurations that you use to assess readiness before deployments are safely rolled out to environments. - -{% data reusables.actions.custom-deployment-protection-rules-limits %} - -### 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. - -You also have the option to prevent self-reviews for deployments to protected environments. If you enable this setting, users who initiate a deployment cannot approve the deployment job, even if they are a required reviewer. This ensures that deployments to protected environments are always reviewed by more than one person. - -For more information on reviewing jobs that reference an environment with required reviewers, see [AUTOTITLE](/actions/managing-workflow-runs/reviewing-deployments). - -{% ifversion fpt %} - -> [!NOTE] -> If you are on a {% data variables.product.prodname_free_user %}, {% data variables.product.prodname_pro %}, or {% data variables.product.prodname_team %} plan, required reviewers are only available for public repositories. - -{% endif %} - -### 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 1 and 43,200 (30 days). Wait time will not count towards your billable time. - -{% ifversion fpt %} - -> [!NOTE] -> If you are on a {% data variables.product.prodname_free_user %}, {% data variables.product.prodname_pro %}, or {% data variables.product.prodname_team %} plan, wait timers are only available for public repositories. - -{% endif %} - -### Deployment branches and tags - -Use deployment branches and tags to restrict which branches and tags can deploy to the environment. Below are the options for deployment branches and tags for an environment: - -* **No restriction:** No restriction on which branch or tag can deploy to the environment. -* **Protected branches only:** Only branches with branch protection rules enabled can deploy to the environment. If no branch protection rules are defined for any branch in the repository, then all branches can deploy. For more information about branch protection rules, see [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches). - - > [!NOTE] - > Deployment workflow runs triggered by tags with the same name as a protected branch and forks with branches that match the protected branch name cannot deploy to the environment. - -* **Selected branches and tags:** Only branches and tags that match your specified name patterns can deploy to the environment. - - If you specify `releases/*` as a deployment branch or tag rule, only a branch or tag whose name begins with `releases/` can deploy to the environment. (Wildcard characters will not match `/`. To match branches or tags that begin with `release/` and contain an additional single slash, use `release/*/*`.) If you add `main` as a 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). - - {% data reusables.actions.branch-and-tag-deployment-rules-configuration %} - -{% ifversion fpt %} - -> [!NOTE] -> Deployment branches and tags are available for all public repositories. For users on {% data variables.product.prodname_pro %} or {% data variables.product.prodname_team %} plans, deployment branches and tags are also available for private repositories. - -{% endif %} - -### Allow administrators to bypass configured protection rules - -By default, administrators can bypass the protection rules and force deployments to specific environments. For more information, see [AUTOTITLE](/actions/managing-workflow-runs/reviewing-deployments#bypassing-environment-protection-rules). - -Alternatively, you can configure environments to disallow bypassing the protection rules for all deployments to the environment. - -{% ifversion fpt %} - -> [!NOTE] -> Allowing administrators to bypass protection rules is only available for public repositories for users on {% data variables.product.prodname_free_user %}, {% data variables.product.prodname_pro %}, and {% data variables.product.prodname_team %} plans. - -{% endif %} - -### Custom deployment protection rules - -{% data reusables.actions.custom-deployment-protection-rules-beta-note %} - -{% data reusables.actions.about-custom-deployment-protection-rules %} For more information, see [AUTOTITLE](/actions/deployment/protecting-deployments/creating-custom-deployment-protection-rules). - -Once custom deployment protection rules have been created and installed on a repository, you can enable the custom deployment protection rule for any environment in the repository. For more information about configuring and enabling custom deployment protection rules, see [AUTOTITLE](/actions/deployment/protecting-deployments/configuring-custom-deployment-protection-rules). - -{% ifversion fpt %} - -> [!NOTE] -> Custom deployment protection rules are only available for public repositories for users on {% data variables.product.prodname_free_user %}, {% data variables.product.prodname_pro %}, and {% data variables.product.prodname_team %} plans. - -{% endif %} - -## 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 [AUTOTITLE](/actions/security-for-github-actions/security-guides/about-secrets). - -{% ifversion fpt %} -> [!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 [AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions#hardening-for-self-hosted-runners). -> * If you are using {% data variables.product.prodname_free_user %}, environment secrets are only available in public repositories. For access to environment secrets in private or internal repositories, you must use {% data variables.product.prodname_pro %}, {% data variables.product.prodname_team %}, or {% data variables.product.prodname_enterprise %}. For more information on switching your plan, see [AUTOTITLE](/billing/managing-the-plan-for-your-github-account/upgrading-your-accounts-plan). - -{% else %} - -> [!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 [AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions#hardening-for-self-hosted-runners). - -{% endif %} - -## Environment variables - -Variables stored in an environment are only available to workflow jobs that reference the environment. These variables are only accessible using the [`vars`](/actions/learn-github-actions/contexts#vars-context) context. For more information, see [AUTOTITLE](/actions/learn-github-actions/variables). - -{% ifversion fpt %} - -> [!NOTE] -> Environment variables are available for all public repositories. For users on {% data variables.product.prodname_pro %} or {% data variables.product.prodname_team %} plans, environment variables are also available for private repositories. - -{% endif %} +* For general information about environments, see [AUTOTITLE](/actions/concepts/use-cases/deploying-with-github-actions#using-environments). +* For information about available rules, see [AUTOTITLE](/actions/reference/deployments-and-environments). ## Creating an environment @@ -170,22 +54,22 @@ Variables stored in an environment are only available to workflow jobs that refe {% data reusables.actions.sidebar-environment %} {% data reusables.actions.new-environment %} {% data reusables.actions.name-environment %} -1. Optionally, specify people or teams that must approve workflow jobs that use this environment. For more information, see [Required reviewers](#required-reviewers). +1. Optionally, specify people or teams that must approve workflow jobs that use this environment. For more information, see [AUTOTITLE](/actions/reference/deployments-and-environments#required-reviewers). 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. Optionally, to prevent users from approving workflows runs that they triggered, select **Prevent self-review**. 1. Click **Save protection rules**. -1. Optionally, specify the amount of time to wait before allowing workflow jobs that use this environment to proceed. For more information, see [Wait timer](#wait-timer). +1. Optionally, specify the amount of time to wait before allowing workflow jobs that use this environment to proceed. For more information, see [AUTOTITLE](/actions/reference/deployments-and-environments#wait-timer). 1. Select **Wait timer**. 1. Enter the number of minutes to wait. 1. Click **Save protection rules**. -1. Optionally, disallow bypassing configured protection rules. For more information, see [Allow administrators to bypass configured protection rules](#allow-administrators-to-bypass-configured-protection-rules). +1. Optionally, disallow bypassing configured protection rules. For more information, see [AUTOTITLE](/actions/reference/deployments-and-environments#allow-administrators-to-bypass-configured-protection-rules). 1. Deselect **Allow administrators to bypass configured protection rules**. 1. Click **Save protection rules**. -1. Optionally, enable any custom deployment protection rules that have been created with {% data variables.product.prodname_github_apps %}. For more information, see [Custom deployment protection rules](#custom-deployment-protection-rules). +1. Optionally, enable any custom deployment protection rules that have been created with {% data variables.product.prodname_github_apps %}. For more information, see [AUTOTITLE](/actions/reference/deployments-and-environments#custom-deployment-protection-rules). 1. Select the custom protection rule you want to enable. 1. Click **Save protection rules**. -1. Optionally, specify what branches and tags can deploy to this environment. For more information, see [Deployment branches and tags](/actions/deployment/targeting-different-environments/managing-environments-for-deployment#deployment-branches-and-tags). +1. Optionally, specify what branches and tags can deploy to this environment. For more information, see [AUTOTITLE](/actions/reference/deployments-and-environments#deployment-branches-and-tags). 1. Select the desired option in the **Deployment branches** dropdown. 1. If you chose **Selected branches and tags**, to add a new rule, click **Add deployment branch or tag rule** 1. In the "Ref type" dropdown menu, depending on what rule you want to apply, click **{% octicon "git-branch" aria-hidden="true" aria-label="git-branch" %} Branch** or **{% octicon "tag" aria-hidden="true" aria-label="tag" %} Tag**. @@ -194,12 +78,12 @@ Variables stored in an environment are only available to workflow jobs that refe {% data reusables.actions.branch-and-tag-deployment-rules-configuration %} 1. Click **Add rule**. -1. 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, see [Environment secrets](#environment-secrets). +1. 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, see [AUTOTITLE](/actions/reference/deployments-and-environments#environment-secrets). 1. Under **Environment secrets**, click **Add Secret**. 1. Enter the secret name. 1. Enter the secret value. 1. Click **Add secret**. -1. Optionally, add environment variables. These variables are only available to workflow jobs that use the environment, and are only accessible using the [`vars`](/actions/learn-github-actions/contexts#vars-context) context. For more information, see [Environment variables](#environment-variables). +1. Optionally, add environment variables. These variables are only available to workflow jobs that use the environment, and are only accessible using the [`vars`](/actions/learn-github-actions/contexts#vars-context) context. For more information, see [AUTOTITLE](/actions/reference/deployments-and-environments#environment-variables). 1. Under **Environment variables**, click **Add Variable**. 1. Enter the variable name. 1. Enter the variable value. diff --git a/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/reviewing-deployments.md b/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/reviewing-deployments.md index fbf0207d210c..b729ac7b5b9d 100644 --- a/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/reviewing-deployments.md +++ b/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/reviewing-deployments.md @@ -12,13 +12,6 @@ redirect_from: - /actions/managing-workflow-runs-and-deployments/managing-deployments/reviewing-deployments --- - -## About required reviews in workflows - -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/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 1. Navigate to the workflow run that requires review. For more information about navigating to a workflow run, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history). diff --git a/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/viewing-deployment-history.md b/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/viewing-deployment-history.md index a19311a76ece..80051fd6b294 100644 --- a/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/viewing-deployment-history.md +++ b/content/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/viewing-deployment-history.md @@ -15,9 +15,7 @@ redirect_from: - /actions/managing-workflow-runs-and-deployments/managing-deployments/viewing-deployment-history --- -## About deployment history - -{% data reusables.actions.about-deployment-with-github-actions %} +## Viewing your repository's deployment history On the deployments page of your repository, you can view the following aspects of your deployments. @@ -32,8 +30,6 @@ On the deployments page of your repository, you can view the following aspects o By default, the deployments page shows currently active deployments from select environments and a timeline of the latest deployments for all environments. -## Viewing your repository's deployment history - 1. In the right-hand sidebar of the home page of your repository, click **Deployments**. 1. Once you are on the "Deployments" page, you can view the following information about your deployment history. * **To view recent deployments for a specific environment**, in the "Environments" section of the left sidebar, click an environment.{% ifversion deployment-dashboard-filter %} diff --git a/content/actions/how-tos/use-cases-and-examples/project-management/index.md b/content/actions/how-tos/use-cases-and-examples/project-management/index.md index 9a82e21169ea..e591fd023836 100644 --- a/content/actions/how-tos/use-cases-and-examples/project-management/index.md +++ b/content/actions/how-tos/use-cases-and-examples/project-management/index.md @@ -10,11 +10,11 @@ children: - /adding-labels-to-issues - /closing-inactive-issues - /commenting-on-an-issue-when-a-label-is-added - - /moving-assigned-issues-on-project-boards - - /removing-a-label-when-a-card-is-added-to-a-project-board-column - /scheduling-issue-creation redirect_from: - /actions/managing-issues-and-pull-requests - /actions/use-cases-and-examples/project-management + - /actions/how-tos/use-cases-and-examples/project-management/moving-assigned-issues-on-project-boards + - /actions/how-tos/use-cases-and-examples/project-management/removing-a-label-when-a-card-is-added-to-a-project-board-column --- diff --git a/content/actions/how-tos/use-cases-and-examples/project-management/moving-assigned-issues-on-project-boards.md b/content/actions/how-tos/use-cases-and-examples/project-management/moving-assigned-issues-on-project-boards.md deleted file mode 100644 index 8eb8a9c34e2f..000000000000 --- a/content/actions/how-tos/use-cases-and-examples/project-management/moving-assigned-issues-on-project-boards.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: 'Moving assigned issues on {% data variables.projects.projects_v1_boards %}' -intro: 'You can use {% data variables.product.prodname_actions %} to automatically move an issue to a specific column on a {% data variables.projects.projects_v1_board %} when the issue is assigned.' -redirect_from: - - /actions/guides/moving-assigned-issues-on-project-boards - - /actions/managing-issues-and-pull-requests/moving-assigned-issues-on-project-boards - - /actions/use-cases-and-examples/project-management/moving-assigned-issues-on-project-boards -versions: - feature: projects-v1 -type: tutorial -topics: - - Workflows - - Project management -shortTitle: Move assigned issues -allowTitleToDifferFromFilename: true ---- - -{% data reusables.projects.project_boards_old %} - -{% data reusables.actions.enterprise-github-hosted-runners %} - -## Introduction - -This tutorial demonstrates how to use the [`alex-page/github-project-automation-plus` action](https://github.com/marketplace/actions/github-project-automation) to automatically move an issue to a specific column on a {% data variables.projects.projects_v1_board %} when the issue is assigned. For example, when an issue is assigned, you can move it into the `In Progress` column your {% data variables.projects.projects_v1_board %}. - -In the tutorial, you will first make a workflow file that uses the [`alex-page/github-project-automation-plus` action](https://github.com/marketplace/actions/github-project-automation). Then, you will customize the workflow to suit your needs. - -## Creating the workflow - -1. {% data reusables.actions.choose-repo %} -1. In your repository, choose a {% data variables.projects.projects_v1_board %}. {% ifversion projects-v1-can-create %} You can use an existing project, or you can create a new project. For more information about creating a project, see [AUTOTITLE](/issues/organizing-your-work-with-project-boards/managing-project-boards/creating-a-project-board).{% endif %} -1. {% data reusables.actions.make-workflow-file %} -1. Copy the following YAML contents into your workflow file. - - ```yaml copy - {% data reusables.actions.actions-not-certified-by-github-comment %} - - {% data reusables.actions.actions-use-sha-pinning-comment %} - - name: Move assigned card - on: - issues: - types: - - assigned - jobs: - move-assigned-card: - runs-on: ubuntu-latest - steps: - - uses: alex-page/github-project-automation-plus@7ffb872c64bd809d23563a130a0a97d01dfa8f43 - with: - project: Docs Work - column: In Progress - repo-token: {% raw %}${{ secrets.PERSONAL_ACCESS_TOKEN }}{% endraw %} - ``` - -1. Customize the parameters in your workflow file: - * Change the value for `project` to the name of your {% data variables.projects.projects_v1_board %}. If you have multiple {% data variables.projects.projects_v1_boards %} with the same name, the `alex-page/github-project-automation-plus` action will act on all projects with the specified name. - * Change the value for `column` to the name of the column where you want issues to move when they are assigned. - * Change the value for `repo-token`: - 1. Create a {% data variables.product.pat_v1 %} with the `repo` scope. For more information, see [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token). - 1. Store this {% data variables.product.pat_generic %} as a secret in your repository. For more information about storing secrets, see [AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions). - 1. In your workflow file, replace `PERSONAL_ACCESS_TOKEN` with the name of your secret. -1. {% data reusables.actions.commit-workflow %} - -## Testing the workflow - -Whenever an issue in your repository is assigned, the issue will be moved to the specified {% data variables.projects.projects_v1_board %} column. If the issue is not already on the {% data variables.projects.projects_v1_board %}, it will be added to the {% data variables.projects.projects_v1_board %}. - -If your repository is user-owned, the `alex-page/github-project-automation-plus` action will act on all projects in your repository or personal account that have the specified project name and column. Likewise, if your repository is organization-owned, the action will act on all projects in your repository or organization that have the specified project name and column. - -Test your workflow by assigning an issue in your repository. - -1. Open an issue in your repository. For more information, see [AUTOTITLE](/issues/tracking-your-work-with-issues/creating-an-issue). -1. Assign the issue. For more information, see [AUTOTITLE](/issues/tracking-your-work-with-issues/assigning-issues-and-pull-requests-to-other-github-users). -1. To see the workflow run that assigning the issue triggered, view the history of your workflow runs. For more information, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history). -1. When the workflow completes, the issue that you assigned should be added to the specified {% data variables.projects.projects_v1_board %} column. - -## Next steps - -* To learn more about additional things you can do with the `alex-page/github-project-automation-plus` action, like deleting or archiving project cards, visit the [`alex-page/github-project-automation-plus` action documentation](https://github.com/marketplace/actions/github-project-automation). diff --git a/content/actions/how-tos/use-cases-and-examples/project-management/removing-a-label-when-a-card-is-added-to-a-project-board-column.md b/content/actions/how-tos/use-cases-and-examples/project-management/removing-a-label-when-a-card-is-added-to-a-project-board-column.md deleted file mode 100644 index eb2e6dade18c..000000000000 --- a/content/actions/how-tos/use-cases-and-examples/project-management/removing-a-label-when-a-card-is-added-to-a-project-board-column.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: 'Removing a label when a card is added to a {% data variables.projects.projects_v1_board %} column' -intro: 'You can use {% data variables.product.prodname_actions %} to automatically remove a label when an issue or pull request is added to a specific column on a {% data variables.projects.projects_v1_board %}.' -redirect_from: - - /actions/guides/removing-a-label-when-a-card-is-added-to-a-project-board-column - - /actions/managing-issues-and-pull-requests/removing-a-label-when-a-card-is-added-to-a-project-board-column - - /actions/use-cases-and-examples/project-management/removing-a-label-when-a-card-is-added-to-a-project-board-column -versions: - feature: projects-v1 -type: tutorial -topics: - - Workflows - - Project management -shortTitle: Remove label when adding card -allowTitleToDifferFromFilename: true ---- - -{% data reusables.projects.project_boards_old %} - -{% data reusables.actions.enterprise-github-hosted-runners %} - -## Introduction - -This tutorial demonstrates how to use the [`actions/github-script` action](https://github.com/marketplace/actions/github-script) along with a conditional to remove a label from issues and pull requests that are added to a specific column on a {% data variables.projects.projects_v1_board %}. For example, you can remove the `needs review` label when project cards are moved into the `Done` column. - -In the tutorial, you will first make a workflow file that uses the [`actions/github-script` action](https://github.com/marketplace/actions/github-script). Then, you will customize the workflow to suit your needs. - -## Creating the workflow - -1. {% data reusables.actions.choose-repo %} -1. Choose a {% data variables.projects.projects_v1_board %} that belongs to the repository. This workflow cannot be used with projects that belong to users or organizations. {% ifversion projects-v1-can-create %} You can use an existing {% data variables.projects.projects_v1_board %}, or you can create a new {% data variables.projects.projects_v1_board %}. For more information about creating a project, see [AUTOTITLE](/issues/organizing-your-work-with-project-boards/managing-project-boards/creating-a-project-board).{% endif %} -1. {% data reusables.actions.make-workflow-file %} -1. Copy the following YAML contents into your workflow file. - - ```yaml copy - name: Remove a label - on: - project_card: - types: - - moved - jobs: - remove_label: - if: github.event.project_card.column_id == '12345678' - runs-on: ubuntu-latest - permissions: - issues: write - pull-requests: write - steps: - - uses: {% data reusables.actions.action-github-script %} - with: - script: | - // this gets the number at the end of the content URL, which should be the issue/PR number - const issue_num = context.payload.project_card.content_url.split('/').pop() - github.rest.issues.removeLabel({ - issue_number: issue_num, - owner: context.repo.owner, - repo: context.repo.repo, - name: ["needs review"] - }) - ``` - -1. Customize the parameters in your workflow file: - * In `github.event.project_card.column_id == '12345678'`, replace `12345678` with the ID of the column where you want to un-label issues and pull requests that are moved there. - - To find the column ID, navigate to your {% data variables.projects.projects_v1_board %}. Next to the title of the column, click {% octicon "kebab-horizontal" aria-label="Column menu" %} then click **Copy column link**. The column ID is the number at the end of the copied link. For example, `24687531` is the column ID for `https://github.com/octocat/octo-repo/projects/1#column-24687531`. - - If you want to act on more than one column, separate the conditions with `||`. For example, `if github.event.project_card.column_id == '12345678' || github.event.project_card.column_id == '87654321'` will act whenever a project card is added to column `12345678` or column `87654321`. The columns may be on different {% data variables.projects.projects_v1_boards %}. - * Change the value for `name` in the `github.rest.issues.removeLabel()` function to the name of the label that you want to remove from issues or pull requests that are moved to the specified column(s). For more information on labels, see [AUTOTITLE](/issues/using-labels-and-milestones-to-track-work/managing-labels#applying-labels-to-issues-and-pull-requests). -1. {% data reusables.actions.commit-workflow %} - -## Testing the workflow - -Every time a project card on a {% data variables.projects.projects_v1_board %} in your repository moves, this workflow will run. If the card is an issue or a pull request and is moved into the column that you specified, then the workflow will remove the specified label from the issue or a pull request. Cards that are notes will not be affected. - -Test your workflow out by moving an issue on your {% data variables.projects.projects_v1_board %} into the target column. - -1. Open an issue in your repository. For more information, see [AUTOTITLE](/issues/tracking-your-work-with-issues/creating-an-issue). -1. Label the issue with the label that you want the workflow to remove. For more information, see [AUTOTITLE](/issues/using-labels-and-milestones-to-track-work/managing-labels#applying-labels-to-issues-and-pull-requests). -1. Add the issue to the {% data variables.projects.projects_v1_board %} column that you specified in your workflow file. For more information, see [AUTOTITLE](/issues/organizing-your-work-with-project-boards/tracking-work-with-project-boards/adding-issues-and-pull-requests-to-a-project-board). -1. To see the workflow run that was triggered by adding the issue to the project, view the history of your workflow runs. For more information, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history). -1. When the workflow completes, the issue that you added to the project column should have the specified label removed. - -## Next steps - -* To learn more about additional things you can do with the `actions/github-script` action, see the [`actions/github-script` action documentation](https://github.com/marketplace/actions/github-script). -* [Search GitHub](https://github.com/search?q=%22uses:+actions/github-script%22&type=code) for examples of workflows using this action. diff --git a/content/actions/reference/deployments-and-environments.md b/content/actions/reference/deployments-and-environments.md new file mode 100644 index 000000000000..4386f068b85a --- /dev/null +++ b/content/actions/reference/deployments-and-environments.md @@ -0,0 +1,121 @@ +--- +title: Deployments and environments +shortTitle: Deployments and environments +intro: 'Find information about deployment protection rules, environment secrets, and environment variables.' +versions: + fpt: '*' + ghes: '*' + ghec: '*' +--- + +## Deployment protection rules + +Deployment protection rules require specific conditions to pass before a job referencing the environment can proceed. You can use deployment protection rules to require a manual approval, delay a job, or restrict the environment to certain branches. You can also create and implement custom protection rules powered by {% data variables.product.prodname_github_apps %} to use third-party systems to control deployments referencing environments configured on {% data variables.product.github %}. + +Third-party systems can be observability systems, change management systems, code quality systems, or other manual configurations that you use to assess readiness before deployments are safely rolled out to environments. + +{% data reusables.actions.custom-deployment-protection-rules-limits %} + +### 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. + +You also have the option to prevent self-reviews for deployments to protected environments. If you enable this setting, users who initiate a deployment cannot approve the deployment job, even if they are a required reviewer. This ensures that deployments to protected environments are always reviewed by more than one person. + +For more information on reviewing jobs that reference an environment with required reviewers, see [AUTOTITLE](/actions/managing-workflow-runs/reviewing-deployments). + +{% ifversion fpt %} + +> [!NOTE] +> If you are on a {% data variables.product.prodname_free_user %}, {% data variables.product.prodname_pro %}, or {% data variables.product.prodname_team %} plan, required reviewers are only available for public repositories. + +{% endif %} + +### 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 1 and 43,200 (30 days). Wait time will not count towards your billable time. + +{% ifversion fpt %} + +> [!NOTE] +> If you are on a {% data variables.product.prodname_free_user %}, {% data variables.product.prodname_pro %}, or {% data variables.product.prodname_team %} plan, wait timers are only available for public repositories. + +{% endif %} + +### Deployment branches and tags + +Use deployment branches and tags to restrict which branches and tags can deploy to the environment. Below are the options for deployment branches and tags for an environment: + +* **No restriction:** No restriction on which branch or tag can deploy to the environment. +* **Protected branches only:** Only branches with branch protection rules enabled can deploy to the environment. If no branch protection rules are defined for any branch in the repository, then all branches can deploy. For more information about branch protection rules, see [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches). + + > [!NOTE] + > Deployment workflow runs triggered by tags with the same name as a protected branch and forks with branches that match the protected branch name cannot deploy to the environment. + +* **Selected branches and tags:** Only branches and tags that match your specified name patterns can deploy to the environment. + + If you specify `releases/*` as a deployment branch or tag rule, only a branch or tag whose name begins with `releases/` can deploy to the environment. (Wildcard characters will not match `/`. To match branches or tags that begin with `release/` and contain an additional single slash, use `release/*/*`.) If you add `main` as a 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). + + {% data reusables.actions.branch-and-tag-deployment-rules-configuration %} + +{% ifversion fpt %} + +> [!NOTE] +> Deployment branches and tags are available for all public repositories. For users on {% data variables.product.prodname_pro %} or {% data variables.product.prodname_team %} plans, deployment branches and tags are also available for private repositories. + +{% endif %} + +### Allow administrators to bypass configured protection rules + +By default, administrators can bypass the protection rules and force deployments to specific environments. For more information, see [AUTOTITLE](/actions/managing-workflow-runs/reviewing-deployments#bypassing-environment-protection-rules). + +Alternatively, you can configure environments to disallow bypassing the protection rules for all deployments to the environment. + +{% ifversion fpt %} + +> [!NOTE] +> Allowing administrators to bypass protection rules is only available for public repositories for users on {% data variables.product.prodname_free_user %}, {% data variables.product.prodname_pro %}, and {% data variables.product.prodname_team %} plans. + +{% endif %} + +### Custom deployment protection rules + +{% data reusables.actions.custom-deployment-protection-rules-beta-note %} + +{% data reusables.actions.about-custom-deployment-protection-rules %} For more information, see [AUTOTITLE](/actions/deployment/protecting-deployments/creating-custom-deployment-protection-rules). + +Once custom deployment protection rules have been created and installed on a repository, you can enable the custom deployment protection rule for any environment in the repository. For more information about configuring and enabling custom deployment protection rules, see [AUTOTITLE](/actions/deployment/protecting-deployments/configuring-custom-deployment-protection-rules). + +{% ifversion fpt %} + +> [!NOTE] +> Custom deployment protection rules are only available for public repositories for users on {% data variables.product.prodname_free_user %}, {% data variables.product.prodname_pro %}, and {% data variables.product.prodname_team %} plans. + +{% endif %} + +## 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 [AUTOTITLE](/actions/security-for-github-actions/security-guides/about-secrets). + +{% ifversion fpt %} +> [!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 [AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions#hardening-for-self-hosted-runners). +> * If you are using {% data variables.product.prodname_free_user %}, environment secrets are only available in public repositories. For access to environment secrets in private or internal repositories, you must use {% data variables.product.prodname_pro %}, {% data variables.product.prodname_team %}, or {% data variables.product.prodname_enterprise %}. For more information on switching your plan, see [AUTOTITLE](/billing/managing-the-plan-for-your-github-account/upgrading-your-accounts-plan). + +{% else %} + +> [!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 [AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions#hardening-for-self-hosted-runners). + +{% endif %} + +## Environment variables + +Variables stored in an environment are only available to workflow jobs that reference the environment. These variables are only accessible using the [`vars`](/actions/learn-github-actions/contexts#vars-context) context. For more information, see [AUTOTITLE](/actions/learn-github-actions/variables). + +{% ifversion fpt %} + +> [!NOTE] +> Environment variables are available for all public repositories. For users on {% data variables.product.prodname_pro %} or {% data variables.product.prodname_team %} plans, environment variables are also available for private repositories. + +{% endif %} diff --git a/content/actions/reference/index.md b/content/actions/reference/index.md index b6dc242ee5f9..b68aa030d3b7 100644 --- a/content/actions/reference/index.md +++ b/content/actions/reference/index.md @@ -14,6 +14,7 @@ children: - /secrets-reference - /evaluate-expressions-in-workflows-and-actions - /contexts-reference + - /deployments-and-environments - /dependency-caching-reference - /metadata-syntax-reference - /actions-limits diff --git a/content/code-security/dependabot/working-with-dependabot/dependabot-options-reference.md b/content/code-security/dependabot/working-with-dependabot/dependabot-options-reference.md index 1d1527fbbd13..ea713fb92387 100644 --- a/content/code-security/dependabot/working-with-dependabot/dependabot-options-reference.md +++ b/content/code-security/dependabot/working-with-dependabot/dependabot-options-reference.md @@ -348,7 +348,7 @@ Supported value: the numeric identifier of a milestone. ## `multi-ecosystem-groups` {% octicon "versions" aria-label="Version updates" height="24" %} -Define groups that span multiple package ecosystems to get a single {% data variables.product.prodname_dependabot %} pull request that updates all supported package ecosystems. This approach helps reduce the number of {% data variables.product.prodname_dependabot %} pull requests you receive and streamlines your dependency update workflow. +Define groups that span multiple package ecosystems to get a single {% data variables.product.prodname_dependabot %} pull request that updates all supported package ecosystems. This approach helps reduce the number of {% data variables.product.prodname_dependabot %} pull requests you receive and streamlines your dependency update workflow. {% data variables.product.prodname_dependabot %} default behavior: @@ -380,7 +380,7 @@ updates: directory: "/" patterns: ["nginx", "redis"] multi-ecosystem-group: "infrastructure" - + - package-ecosystem: "terraform" directory: "/" patterns: ["aws"] @@ -804,19 +804,19 @@ Defines a **cooldown period** for dependency updates to delay updates for a conf ### **How Cooldown Works** -* When {% data variables.product.prodname_dependabot %} runs updates as per defined schedule, it checks the **cooldown settings** to determine if new release for dependency is still within its cooldown period. -* If new version release date is within the cooldown period, dependency version update is **filtered out** and will not be updated until the cooldown period expires. +* When {% data variables.product.prodname_dependabot %} runs updates as per defined schedule, it checks the **cooldown settings** to determine if new release for dependency is still within its cooldown period. +* If new version release date is within the cooldown period, dependency version update is **filtered out** and will not be updated until the cooldown period expires. * Once the cooldown period ends for new version, the dependency update proceeds based on the standard update strategy defined in `dependabot.yml`. Without **`cooldown`** (default behaviour): -* Dependabot checks for updates according to the scheduled defined via `schedule.interval`. -* All new versions are considered for updates **immediately**. +* Dependabot checks for updates according to the scheduled defined via `schedule.interval`. +* All new versions are considered for updates **immediately**. With **`cooldown`** enabled: -* {% data variables.product.prodname_dependabot %} checks for updates based on the defined `schedule.interval` settings. -* **Releases within the cooldown period are ignored.** +* {% data variables.product.prodname_dependabot %} checks for updates based on the defined `schedule.interval` settings. +* **Releases within the cooldown period are ignored.** * {% data variables.product.prodname_dependabot %} updates the dependency to the latest available version **that are no longer in cooldown period** following the configured `versioning-strategy`. ### **Cooldown Configuration** @@ -843,7 +843,7 @@ With **`cooldown`** enabled: | **Docker Compose** | No | | **Dotnet SDK** | Yes | | **Elm** | Yes | -| **Github Actions** | No | +| **{% data variables.product.prodname_actions %}** | No | | **Gitsubmodule** | No | | **Gomod (Go Modules)**| Yes | | **Gradle** | Yes | @@ -881,7 +881,7 @@ updates: default-days: 5 semver-major-days: 30 semver-minor-days: 7 - semver-patch-days: 3 + semver-patch-days: 3 include: - "requests" - "numpy" diff --git a/content/copilot/concepts/copilot-billing/about-billing-for-github-copilot-in-your-enterprise.md b/content/copilot/concepts/copilot-billing/about-billing-for-github-copilot-in-your-enterprise.md index 09cc7a65651d..6229187b4a2d 100644 --- a/content/copilot/concepts/copilot-billing/about-billing-for-github-copilot-in-your-enterprise.md +++ b/content/copilot/concepts/copilot-billing/about-billing-for-github-copilot-in-your-enterprise.md @@ -35,6 +35,7 @@ Billed users are calculated at the end of each billing cycle, based on the numbe * **Any seat assigned part way through the billing cycle** is prorated based on the number of days remaining in the cycle. * **Any seat assignment cancellation during a billing cycle** takes effect at the beginning of the next cycle. The user can access {% data variables.product.prodname_copilot_short %} until the end of the cycle. * **Any user removed from an organization with {% data variables.product.prodname_copilot_short %} during a billing cycle** loses access to {% data variables.product.prodname_copilot_short %} immediately. Billing for that user stops at the end of the cycle. If the user is restored to the organization during the billing cycle, they regain access to {% data variables.product.prodname_copilot_short %} immediately. +* **When {% data variables.product.prodname_copilot_short %} is disabled at the enterprise or organization level** any user with a {% data variables.product.prodname_copilot_short %} license will lose access to {% data variables.product.prodname_copilot_short %} immediately. Billing for that user stops at the end of the cycle. If the user is restored to the organization during the billing cycle, they regain access to {% data variables.product.prodname_copilot_short %} immediately. Your enterprise will be charged on whichever payment method you’ve set up for the enterprise account, such as a credit card or a Microsoft Azure subscription.