Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/doc/ci
diff options
context:
space:
mode:
authorGitLab Bot <gitlab-bot@gitlab.com>2023-05-22 21:10:38 +0300
committerGitLab Bot <gitlab-bot@gitlab.com>2023-05-22 21:10:38 +0300
commit7e2f555a6dc37839727dee130d8ed4421b680d42 (patch)
treef2bcca7814bbaa6ee50e14830bc3a74307b1148e /doc/ci
parent4ec96676406da695de083b4f394290902da2a964 (diff)
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/ci')
-rw-r--r--doc/ci/environments/deployment_approvals.md15
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: