diff options
Diffstat (limited to 'doc/user/project/merge_requests/approvals/index.md')
-rw-r--r-- | doc/user/project/merge_requests/approvals/index.md | 23 |
1 files changed, 17 insertions, 6 deletions
diff --git a/doc/user/project/merge_requests/approvals/index.md b/doc/user/project/merge_requests/approvals/index.md index 3c47c2af344..40345f33cb2 100644 --- a/doc/user/project/merge_requests/approvals/index.md +++ b/doc/user/project/merge_requests/approvals/index.md @@ -11,11 +11,21 @@ disqus_identifier: 'https://docs.gitlab.com/ee/user/project/merge_requests/merge > Redesign [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8 and [feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/10685) in 12.0. You can configure your merge requests so that they must be approved before -they can be merged. You can do this by creating [rules](rules.md) or by specifying -a list of users who act as [code owners](../../code_owners.md) for specific files. - -You can configure merge request approvals for each project. In higher GitLab tiers, -Administrators of self-managed GitLab instances can configure approvals +they can be merged. While [GitLab Free](https://about.gitlab.com/pricing/) allows +all users with Developer or greater [permissions](../../../permissions.md) to +approve merge requests, these approvals are [optional](#optional-approvals). +[GitLab Premium](https://about.gitlab.com/pricing/) and +[GitLab Ultimate](https://about.gitlab.com/pricing/) provide additional +flexibility: + +- Create required [rules](rules.md) about the number and type of approvers before work can merge. +- Specify a list of users who act as [code owners](../../code_owners.md) for specific files, + and require their approval before work can merge. + +You can configure merge request approvals on a per-project basis. Administrators of +[GitLab Premium](https://about.gitlab.com/pricing/) and +[GitLab Ultimate](https://about.gitlab.com/pricing/) self-managed GitLab instances +can also configure approvals [for the entire instance](../../../admin_area/merge_requests_approvals.md). ## How approvals work @@ -60,7 +70,7 @@ a merge request. After a merge request receives the [number and type of approvals](rules.md) you configure, it can merge unless it's blocked for another reason. Merge requests can be blocked by other problems, -such as merge conflicts, [pending discussions](../../../discussions/index.md#only-allow-merge-requests-to-be-merged-if-all-threads-are-resolved), +such as merge conflicts, [pending discussions](../../../discussions/index.md#prevent-merge-unless-all-threads-are-resolved), or a [failed CI/CD pipeline](../merge_when_pipeline_succeeds.md). To prevent merge request authors from approving their own merge requests, @@ -94,6 +104,7 @@ Without the approvals, the work cannot merge. Required approvals enable multiple database, for all proposed code changes. - Use the [code owners of changed files](rules.md#code-owners-as-eligible-approvers), to determine who should review the work. +- Require an [approval before merging code that causes test coverage to decline](../../../../ci/pipelines/settings.md#coverage-check-approval-rule) - [Require approval from a security team](../../../application_security/index.md#security-approvals-in-merge-requests) before merging code that could introduce a vulnerability. **(ULTIMATE)** |