diff options
Diffstat (limited to 'doc/ci/environments')
| -rw-r--r-- | doc/ci/environments/deployment_approvals.md | 17 | ||||
| -rw-r--r-- | doc/ci/environments/deployment_safety.md | 2 | ||||
| -rw-r--r-- | doc/ci/environments/index.md | 17 | ||||
| -rw-r--r-- | doc/ci/environments/protected_environments.md | 2 |
4 files changed, 27 insertions, 11 deletions
diff --git a/doc/ci/environments/deployment_approvals.md b/doc/ci/environments/deployment_approvals.md index a4815a85bc1..a95c47ca4b0 100644 --- a/doc/ci/environments/deployment_approvals.md +++ b/doc/ci/environments/deployment_approvals.md @@ -113,6 +113,23 @@ NOTE: To protect, update, or unprotect an environment, you must have at least the Maintainer role. +### Optional settings + +#### Allow self-approval + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/381418) in GitLab 15.8. + +By default, a user who triggered a deployment pipeline can't self-approve the deployment jobs. +You can allow the self-approval by the following settings: + +1. On the top bar, select **Main menu > Projects** and find your project. +1. On the left sidebar, select **Settings > CI/CD**. +1. Expand **Protected environments**. +1. From the **Approval options**, check **Allow pipeline triggerer to approve deployment**. + +By enabling this, when a pipeline runs, deployment jobs will automatically be approved in the pipeline +if the triggerer is allowed to approve, otherwise nothing happens. + ## Approve or reject a deployment > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/342180/) in GitLab 14.9 diff --git a/doc/ci/environments/deployment_safety.md b/doc/ci/environments/deployment_safety.md index 1e4eb54c559..cf82238564e 100644 --- a/doc/ci/environments/deployment_safety.md +++ b/doc/ci/environments/deployment_safety.md @@ -130,7 +130,7 @@ ensure that deployments do not happen unexpectedly. Production secrets are needed to deploy successfully. For example, when deploying to the cloud, cloud providers require these secrets to connect to their services. In the project settings, you can -define and protect CI/CD variables for these secrets. [Protected variables](../variables/index.md#protected-cicd-variables) +define and protect CI/CD variables for these secrets. [Protected variables](../variables/index.md#protect-a-cicd-variable) are only passed to pipelines running on [protected branches](../../user/project/protected_branches.md) or [protected tags](../../user/project/protected_tags.md). The other pipelines don't get the protected variable. You can also diff --git a/doc/ci/environments/index.md b/doc/ci/environments/index.md index 0c412c85e47..514a0b255c5 100644 --- a/doc/ci/environments/index.md +++ b/doc/ci/environments/index.md @@ -436,6 +436,8 @@ There are multiple ways to clean up [dynamic environments](#create-a-dynamic-env - If you do _NOT_ use [merge request pipelines](../pipelines/merge_request_pipelines.md), GitLab stops an environment [when the associated feature branch is deleted](#stop-an-environment-when-a-branch-is-deleted). - If you set [an expiry period to an environment](../yaml/index.md#environmentauto_stop_in), GitLab stops an environment [when it's expired](#stop-an-environment-after-a-certain-time-period). +To stop stale environments, you can [use the API](../../api/environments.md#stop-stale-environments). + #### Stop an environment when a branch is deleted You can configure environments to stop when a branch is deleted. @@ -534,10 +536,6 @@ Also in the example, `GIT_STRATEGY` is set to `none`. If the `stop_review_app` job is [automatically triggered](../environments/index.md#stop-an-environment), the runner won't try to check out the code after the branch is deleted. -The example also overwrites global variables. If your `stop` `environment` job depends -on global variables, use [anchor variables](../yaml/yaml_optimization.md#yaml-anchors-for-variables) when you set the `GIT_STRATEGY` -to change the job without overriding the global variables. - The `stop_review_app` job **must** have the following keywords defined: - `when`, defined at either: @@ -926,12 +924,17 @@ NOTE: GitLab preserves all commits as [`keep-around` refs](../../user/project/repository/reducing_the_repo_size_using_git.md) so that deployed commits are not garbage collected, even if it's not referenced by the deployment refs. -### Scope environments with specs +### Limit the environment scope of a CI/CD variable > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2112) in GitLab Premium 9.4. > - Environment scoping for CI/CD variables was [moved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30779) from GitLab Premium to GitLab Free in 12.2. > - Environment scoping for Group CI/CD variables [added](https://gitlab.com/gitlab-org/gitlab/-/issues/2874) to GitLab Premium in 13.11. +By default, all [CI/CD variables](../variables/index.md) are available to any job in a pipeline. Therefore, if a project uses a +compromised tool in a test job, it could expose all CI/CD variables that a deployment job used. This is +a common scenario in supply chain attacks. GitLab helps mitigate supply chain attacks by limiting +the environment scope of a variable. + You can limit the environment scope of a CI/CD variable by defining which environments it can be available for. For example, if the environment scope is `production`, then only the jobs @@ -943,10 +946,6 @@ any job can have this variable, regardless of whether an environment is defined. If the environment scope is `review/*`, then jobs with environment names starting with `review/` would have that variable available. -Some GitLab features can behave differently for each environment. -For example, you can -[create a project CI/CD variable to be injected only into a production environment](../variables/index.md#limit-the-environment-scope-of-a-cicd-variable). - In most cases, these features use the _environment specs_ mechanism, which offers an efficient way to implement scoping in each environment group. diff --git a/doc/ci/environments/protected_environments.md b/doc/ci/environments/protected_environments.md index 638bcf77967..b72ee9b388f 100644 --- a/doc/ci/environments/protected_environments.md +++ b/doc/ci/environments/protected_environments.md @@ -210,7 +210,7 @@ configured: This ensures that only operators can configure the organization-wide deployment ruleset. - Developers should be given no more than the Developer role - for the top-level group, or explicitly given the Owner role for a child project + for the top-level group, or explicitly given the Owner role for a child project. They do *not* have access to the CI/CD configurations in the top-level group, so operators can ensure that the critical configuration won't be accidentally changed by the developers. |