Deployment approvals (PREMIUM)
- Introduced in GitLab 14.7 with a flag named
deployment_approvals
. Disabled by default.- Feature flag removed in GitLab 14.8.
WARNING: This feature is in a Beta stage and subject to change without prior notice.
It may be useful to require additional approvals before deploying to certain protected environments (for example, production). This pre-deployment approval requirement is useful to accommodate testing, security, or compliance processes that must happen before each deployment.
When a protected environment requires one or more approvals, all deployments to that environment become blocked and wait for the required approvals from the Allowed to Deploy
list before running.
NOTE: See the epic for planned features.
Requirements
- Basic knowledge of GitLab Environments and Deployments.
- Basic knowledge of Protected Environments.
Configure deployment approvals for a project
To configure deployment approvals for a project:
Create a deployment job
Create a deployment job in the .gitlab-ci.yaml
file of the desired project. The job does not need to be manual (when: manual
).
Example:
stages:
- deploy
production:
stage: deploy
script:
- 'echo "Deploying to ${CI_ENVIRONMENT_NAME}"'
environment:
name: ${CI_JOB_NAME}
Require approvals for a protected environment
There are two ways to configure the approval requirements:
- Unified approval setting ... You can define who can execute and approve deployments. This is useful when there is no separation of duties between executors and approvers in your organization.
- Multiple approval rules ... You can define who can execute or approve deployments. This is useful when there is a separation of duties between executors and approvers in your organization.
NOTE: Multiple approval rules is a more flexible option than the unified approval setting, thus both configurations shouldn't co-exist and multiple approval rules takes the precedence over the unified approval setting if it happens.
Unified approval setting
NOTE: At this time, it is not possible to require approvals for an existing protected environment. The workaround is to unprotect the environment and configure approvals when re-protecting the environment.
There are two ways to configure approvals for a protected environment:
- Using the UI
- Set the Required approvals field to 1 or more.
- Using the REST API
2. Set the
required_approval_count
field to 1 or more.
After this is configured, all jobs deploying to this environment automatically go into a blocked state and wait for approvals before running. Ensure that the number of required approvals is less than the number of users allowed to deploy.
Example:
curl --header 'Content-Type: application/json' --request POST \
--data '{"name": "production", "deploy_access_levels": [{"group_id": 9899826}], "required_approval_count": 1}' \
--header "PRIVATE-TOKEN: <your_access_token>" \
"https://gitlab.example.com/api/v4/projects/22034114/protected_environments"
NOTE: To protect, update, or unprotect an environment, you must have at least the Maintainer role.
Multiple approval rules
Introduced in GitLab 14.10 with a flag named
deployment_approval_rules
. Disabled by default.
- Using the REST API.
-
deploy_access_levels
represents which entity can execute the deployment job. -
approval_rules
represents which entity can approve the deployment job.
-
After this is configured, all jobs deploying to this environment automatically go into a blocked state and wait for approvals before running. Ensure that the number of required approvals is less than the number of users allowed to deploy.
Example:
curl --header 'Content-Type: application/json' --request POST \
--data '{"name": "production", "deploy_access_levels": [{"group_id": 138}], "approval_rules": [{"group_id": 134}, {"group_id": 135, "required_approvals": 2}]}' \
--header "PRIVATE-TOKEN: <your_access_token>" \
"https://gitlab.example.com/api/v4/groups/128/protected_environments"
With this setup:
- The operator group (
group_id: 138
) has permission to execute the deployment jobs to theproduction
environment in the organization (group_id: 128
). - The QA tester group (
group_id: 134
) and security group (group_id: 135
) have permission to approve the deployment jobs to theproduction
environment in the organization (group_id: 128
). - Unless two approvals from security group and one approval from QA tester group have been collected, the operator group can't execute the deployment jobs.
NOTE: To protect, update, or unprotect an environment, you must have at least the Maintainer role.
Approve or reject a deployment
Introduced in GitLab 14.9
Using either the GitLab UI or the API, you can:
- Approve a deployment to allow it to proceed.
- Reject a deployment to prevent it.
Approve or reject a deployment using the UI
Prerequisites:
- Permission to deploy to the protected environment.
To approve or reject a deployment to a protected environment using the UI:
- On the top bar, select Menu > Projects and find your project.
- On the left sidebar, select Deployments > Environments.
- In the deployment's row, select Approval options ({thumb-up}).
- Select Approve or Reject.
NOTE: This feature might not work as expected when Multiple approval rules is configured. See the issue for planned improvement.
Approve or reject a deployment using the API
Prerequisites:
- Permission to deploy to the protected environment.
To approve or reject a deployment to a protected environment using the API, pass the required attributes. For more details, see Approve or reject a blocked deployment.
Example:
curl --data "status=approved&comment=Looks good to me" \
--header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/deployments/1/approval"
How to see blocked deployments
Using the UI
- On the top bar, select Menu > Projects and find your project.
- On the left sidebar, select Deployments > Environments.
- Select the environment being deployed to.
- Look for the
blocked
label.
Using the API
Use the Deployments API to see deployments.
- The
status
field indicates if a deployment is blocked. - When the unified approval setting is configured:
- The
pending_approval_count
field indicates how many approvals are remaining to run a deployment. - The
approvals
field contains the deployment's approvals.
- The
- When the multiple approval rules is configured:
- The
approval_summary
field contains the current approval status per rule.
- The
Related features
For details about other GitLab features aimed at protecting deployments, see safe deployments.