Skip to content

Merge request approval settings (PREMIUM ALL)

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:

  1. Go to your project and select Settings > Merge requests.
  2. Expand Approvals.

Approval settings

These settings limit who can approve merge requests:

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:

  1. On the left sidebar, select Settings > Merge requests.
  2. In the Merge request approvals section, scroll to Approval settings and clear the Prevent approval by author checkbox.
  3. 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 approvals by users who add commits

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:

  1. On the left sidebar, select Settings > Merge requests.
  2. 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.
  3. 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.

For more information, see the official Git documentation.

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:

  1. On the left sidebar, select Settings > Merge requests.
  2. In the Merge request approvals section, scroll to Approval settings and select Prevent editing approval rules in merge requests.
  3. Select Save changes.

This change affects all open merge requests.

When this field is changed, it can affect all open merge requests depending on the setting:

  • If users could edit approval rules previously, and you disable this behavior, all open merge requests are updated to enforce the approval rules.
  • If users could not edit approval rules previously, and you enable approval rule editing, open merge requests remain unchanged. This preserves any changes already made to approval rules in those merge requests.

Require user re-authentication to approve

  • Requiring re-authentication by using SAML authentication for GitLab.com groups introduced in GitLab 16.6 with a flag named ff_require_saml_auth_to_approve. Disabled by default.
  • Requiring re-authentication by using SAML authentication for self-managed instances introduced in GitLab 16.7 with a flag named ff_require_saml_auth_to_approve. Disabled by default.
  • Enabled ff_require_saml_auth_to_approve by default in GitLab 16.8 for GitLab.com and self-managed instances.

FLAG: On self-managed GitLab, by default requiring re-authentication by using SAML authentication is available. To hide the feature, an administrator can disable the feature flag named ff_require_saml_auth_to_approve. On GitLab.com, this feature is available.

You can force potential approvers to first authenticate with either:

  • A password.
  • SAML.

This permission enables an electronic signature for approvals, such as the one defined by Code of Federal Regulations (CFR) Part 11). This setting is only available on top-level groups. For more information, see Settings cascading.

  1. Enable password authentication and SAML authentication. For more information on:
  2. On the left sidebar, select Settings > Merge requests.
  3. In the Merge request approvals section, scroll to Approval settings and select Require user re-authentication (password or SAML) to approve.
  4. Select Save changes.

Remove all approvals when commits are added to the source branch

By default, an approval on a merge request is removed when you add more changes after the approval. In GitLab Premium and Ultimate tiers, to keep existing approvals after more changes are added to the merge request:

  1. On the left sidebar, select Settings > Merge requests.

  2. In the Merge request approvals section, scroll to Approval settings and clear the Remove all approvals checkbox.

    NOTE: This setting is not available in GitLab Free.

  3. 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 when a commit is added:

Prerequisites:

  • You must have at least the Maintainer role for a project.

To do this:

  1. On the left sidebar, select Settings > Merge requests.
  2. In the Merge request approvals section, scroll to Approval settings and select Remove approvals by Code Owners if their files changed.
  3. Select Save changes.

Settings cascading

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.

Related topics