Merge request approval settings (PREMIUM)
You can configure the settings for merge request approvals to ensure the approval rules meet your use case. You can also configure approval rules, which define the number and type of users who must approve work before it's merged. Merge request approval settings define how those rules are applied as a merge request moves toward completion.
Edit merge request approval settings
To view or edit merge request approval settings:
- Go to your project and select Settings > Merge requests.
- Expand Approvals.
Approval settings
These settings limit who can approve merge requests:
- Prevent approval by author: Prevents the author of a merge request from approving it.
- Prevent approvals by users who add commits: Prevents users who add commits to a merge request from also approving it.
- Prevent editing approval rules in merge requests: Prevents users from overriding project level approval rules on merge requests.
- Require user password to approve: Force potential approvers to first authenticate with a password.
- Code Owner approval removals: Define what happens to existing approvals when
commits are added to the merge request.
- Keep approvals: Do not remove any approvals.
- Remove all approvals: Remove all existing approvals.
- Remove approvals by Code Owners if their files changed: If a Code Owner approves a merge request, and a later commit changes files they are a Code Owner for, their approval is removed.
Prevent approval by author
Moved to GitLab Premium in 13.9.
By default, the author of a merge request cannot approve it. To change this setting:
- On the left sidebar, select Settings > Merge requests.
- In the Merge request approvals section, scroll to Approval settings and clear the Prevent approval by author checkbox.
- Select Save changes.
Authors can edit the approval rule in an individual merge request and override this setting, unless you configure one of these options:
- Prevent overrides of default approvals at the project level.
- (Self-managed instances only) Prevent overrides of default approvals at the instance level. When configured at the instance level, you can't edit this setting at the project or individual merge request levels.
Prevent approvals by users who add commits
Moved to GitLab Premium in 13.9.
By default, users who commit to a merge request can still approve it. At both the project level or instance level, you can prevent committers from approving merge requests that are partially their own. To do this:
- On the left sidebar, select Settings > Merge requests.
- In the Merge request approvals section, scroll to Approval settings and select Prevent approvals by users who add commits. If this checkbox is cleared, an administrator has disabled it at the instance level, and it can't be changed at the project level.
- Select Save changes.
Depending on your version of GitLab, code owners who commit to a merge request may or may not be able to approve the work:
- In GitLab 13.10 and earlier, code owners who commit to a merge request can approve it, even if the merge request affects files they own.
- In GitLab 13.11 and later, code owners who commit to a merge request cannot approve it, when the merge request affects files they own.
To learn more about the differences between authors and committers, read the official Git documentation for an explanation.
Prevent editing approval rules in merge requests
By default, users can override the approval rules you create for a project on a per-merge-request basis. If you don't want users to change approval rules on merge requests, you can disable this setting:
- On the left sidebar, select Settings > Merge requests.
- In the Merge request approvals section, scroll to Approval settings and select Prevent editing approval rules in merge requests.
- Select Save changes.
This change affects all open merge requests.
Require user password to approve
- Introduced in GitLab 12.0.
- Moved to GitLab Premium in 13.9.
You can force potential approvers to first authenticate with a password. This permission enables an electronic signature for approvals, such as the one defined by Code of Federal Regulations (CFR) Part 11):
- Enable password authentication for the web interface, as described in the sign-in restrictions documentation.
- On the left sidebar, select Settings > Merge requests.
- In the Merge request approvals section, scroll to Approval settings and select Require user password to approve.
- Select Save changes.
Remove all approvals when commits are added to the source branch
By default, an approval on a merge request remains in place, even if you add more changes after the approval. If you want to remove all existing approvals on a merge request when more changes are added to it:
- On the left sidebar, select Settings > Merge requests.
- In the Merge request approvals section, scroll to Approval settings and select Remove all approvals.
- Select Save changes.
Approvals aren't removed when a merge request is rebased from the UI However, approvals are reset if the target branch is changed.
Remove approvals by Code Owners if their files changed
Introduced in GitLab 15.3.
If you only want to remove approvals by Code Owners whose files have been changed:
Prerequisite:
- You must have at least the Maintainer role for a project.
To do this:
- On the left sidebar, select Settings > Merge requests.
- In the Merge request approvals section, scroll to Approval settings and select Remove approvals by Code Owners if their files changed.
- Select Save changes.
Code coverage check approvals
You can require specific approvals if a merge request would result in a decline in code test coverage.
To learn more, see Coverage check approval rule.
Settings cascading
- Introduced in GitLab 14.4. Deployed behind the
group_merge_request_approval_settings_feature_flag
flag, disabled by default.- Enabled by default in GitLab 14.5.
- Feature flag
group_merge_request_approval_settings_feature_flag
removed in GitLab 14.9.
You can also enforce merge request approval settings:
- At the instance level, which apply to all groups on an instance and, therefore, all projects.
- On a top-level group, which apply to all subgroups and projects.
If the settings are inherited by a group or project, they cannot be changed in the group or project that inherited them.