diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2023-05-22 21:10:38 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2023-05-22 21:10:38 +0300 |
commit | 7e2f555a6dc37839727dee130d8ed4421b680d42 (patch) | |
tree | f2bcca7814bbaa6ee50e14830bc3a74307b1148e /doc/ci/environments | |
parent | 4ec96676406da695de083b4f394290902da2a964 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/ci/environments')
-rw-r--r-- | doc/ci/environments/deployment_approvals.md | 15 |
1 files changed, 12 insertions, 3 deletions
diff --git a/doc/ci/environments/deployment_approvals.md b/doc/ci/environments/deployment_approvals.md index 87ef9c924ba..3cf14357595 100644 --- a/doc/ci/environments/deployment_approvals.md +++ b/doc/ci/environments/deployment_approvals.md @@ -51,7 +51,7 @@ Example: There are two ways to configure the approval requirements: -- [Unified approval setting](#unified-approval-setting) ... You can define who can execute **and** approve deployments. +- [Unified approval setting](#unified-approval-setting-deprecated) ... 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](#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. @@ -60,11 +60,18 @@ 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 +<!--- start_remove The following content will be removed on remove_date: '2024-05-22' --> + +#### Unified approval setting (deprecated) > - UI configuration [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/378447) in GitLab > 15.11. +WARNING: +This feature was [deprecated](https://gitlab.com/groups/gitlab-org/-/epics/9662) in GitLab 16.1 and is planned for removal +in 17.0. Use [multiple approval rules](https://gitlab.com/gitlab-org/gitlab/-/issues/404579) instead. This change +is a breaking change. + To configure approvals for a protected environment: - Using the [REST API](../../api/protected_environments.md#protect-a-single-environment), @@ -85,6 +92,8 @@ NOTE: To protect, update, or unprotect an environment, you must have at least the Maintainer role. +<!--- end_remove --> + #### Multiple approval rules > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/345678) in GitLab 14.10 with a flag named `deployment_approval_rules`. Disabled by default. @@ -252,7 +261,7 @@ The approval status details are shown: Use the [Deployments API](../../api/deployments.md#get-a-specific-deployment) to see deployments. - The `status` field indicates if a deployment is blocked. -- When the [unified approval setting](#unified-approval-setting) is configured: +- When the [unified approval setting](#unified-approval-setting-deprecated) 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. - When the [multiple approval rules](#multiple-approval-rules) is configured: |