doc/user/project/merge_requests/approvals/rules.md
{{< details >}}
{{< /details >}}
Approval rules define how many approvals a merge request must receive before it can be merged, and which users should do the approving. They can be used in conjunction with code owners to ensure that changes are reviewed both by the group maintaining the feature, and any groups responsible for specific areas of oversight.
You can define approval rules:
You can configure approval rules:
If you don't define a default approval rule, any user can approve a merge request. Even if you don't define a rule, you can still enforce a minimum number of required approvers in the project's settings.
Merge requests that target a different project, such as from a fork to the upstream project, use the default approval rules from the target (upstream) project, not the source (fork).
Merge request approvals can be configured globally to apply across all (or a subset) projects with policies. Merge request approval policies also provide additional flexibility with more granular configuration options.
Prerequisites:
To add a merge request approval rule:
0 makes
the rule optional, and any number greater than 0
creates a required rule.
Maximum number of required approvals is 100.Your configuration for approval rule overrides determines if the new rule is applied to existing merge requests:
Prerequisites:
To edit a merge request approval rule:
0 makes
the rule optional, and any number greater than 0
creates a required rule.
Maximum number of required approvals is 100.Prerequisites:
To delete a merge request approval rule:
To enforce multiple approval rules on a merge request, add multiple default approval rules for a project.
When an eligible approver approves a merge request, it reduces the number of approvals left (the Approvals column) for all rules that the approver belongs to:
<i class="fa-youtube-play" aria-hidden="true"></i> For an overview, see the multiple approvers video.
To get email notifications every time a merge request you're eligible to approve is created:
You can override the merge request approval rules for a project by either:
Prerequisites:
To override approvers of a merge request:
Administrators can change the merge request approvals settings to prevent users from overriding approval rules for merge requests.
To create an approval rule which requires more than one approval:
To require multiple approvals for a rule, you can also
use the Merge request approvals API
to set the approvals_required attribute to 2 or more.
Merge request approvals can be optional for projects where approvals are appreciated, but not required. To make an approval rule optional:
0.To make an approval rule optional, you can also use the API to
update an approval rule for a project,
and set the approvals_required attribute to 0.
Approval rules are often relevant only to specific branches, like your default branch. To configure an approval rule for certain branches:
Before users with the Planner or Reporter role can merge to a protected branch, you have to grant them permission to approve merge requests. Some users (like managers) might not need permission to push or merge code, but still need oversight on proposed work.
Users with the Planner or Reporter role can approve merge requests only through regular approval rules. Code owner approval rules require users to have the Developer, Maintainer, or Owner role. For more information, see eligible approvers.
Prerequisites:
All Branches or All protected branches settings.To enable approval permissions for these users without granting them push access:
{{< details >}}
{{< /details >}}
{{< history >}}
security_policy_approval_notification. Enabled by default.security_policy_approval_notification removed.{{< /history >}}
You can use merge request approval policies to define security approvals based on the status of vulnerabilities in the merge request and the default branch. Details for each security policy is shown in the Security Approvals section of your Merge Request configuration.
The security approval rules are applied to all merge requests until the pipeline is complete. The application of the security approval rules prevents users from merging in code before the security scans run. After the pipeline is complete, the security approval rules are checked to determine if the security approvals are still required. In case the scanners in the pipeline identify an issue and security approvals are required, a bot comment is generated on the merge request to indicate which steps are needed to proceed.
These policies are both created and edited in the security policy editor.
To be eligible as an approver for your project, a user must be a direct member of at least one of the following:
Users with the Developer role can approve merge requests if one of the following is true:
Users with the Planner or Reporter role can approve only if all of the following are true:
To show who has participated in the merge request review, the Approvals widget in a merge request displays a Commented by column. This column lists eligible approvers who commented on the merge request. It helps authors and reviewers identify who to contact with questions about the merge request's content.
If the number of required approvals is greater than the number of assigned approvers, approvals from other users with the Developer, Maintainer, or Owner role in the project count toward meeting the required number of approvals, even if the users were not explicitly listed in the approval rules.
If you add code owners to your repository, the owners of files become eligible approvers in the project. To enable this merge request approval rule:
You can also require code owner approval for protected branches.
The following tables show how membership type affects eligibility for both approval rules and Code Owners.
When you assign individual users as approvers for approval rules or reference users in CODEOWNERS
files, like @username:
| Membership type | Approval rules | Code Owners |
|---|---|---|
| Direct member of the project | {{< yes >}} | {{< yes >}} |
| Direct member of the project's group | {{< yes >}} | {{< yes >}} |
| Inherited member of the project's group | {{< yes >}} | {{< yes >}} |
| Direct member of a group invited to the project | {{< yes >}} | {{< yes >}} |
| Inherited member of a group invited to the project | {{< no >}} | {{< no >}} |
| Direct member of a group invited to the project's group | {{< yes >}} | {{< yes >}} |
| Inherited member of a group invited to the project's group | {{< no >}} | {{< no >}} |
| Direct member of a group invited to the project's group's parent groups | {{< yes >}} | {{< yes >}} |
| Inherited member of a group invited to the project's group's parent groups | {{< no >}} | {{< no >}} |
When you assign groups as approvers for approval rules or reference groups in CODEOWNERS files,
like @group-name, only direct members of eligible groups can provide approvals:
| Group type | Approval rules | Code Owners |
|---|---|---|
| Groups invited to the project | {{< yes >}} | {{< yes >}} |
| Groups invited to the project's group | {{< yes >}} | {{< no >}} |
| Groups invited to a parent of the project's group | {{< yes >}} | {{< no >}} |
| The project's group | {{< yes >}} | {{< yes >}} |
| A parent of the project's group | {{< yes >}} | {{< yes >}} |
[!note] For group-based approvals, only direct members of the group can approve merge requests. Inherited members of the eligible groups cannot provide approvals.
You can add a group of users as approvers. All direct members of this group can approve the rule. Inherited members cannot approve the rule.
Typically the group is a subgroup in your top-level namespace, unless you are collaborating with an external group. If you are collaborating with another group and want to use members of that group as approvers, you can either:
A user's membership in an approver group determines their individual approval permissions in the following ways:
As a workaround for this validation error, you can delete the approval rule through the API.
For more information about this validation error, read issue 285129.
A group created to handle approvals may be created in a different area of the project hierarchy than the project requiring review. If this happens, members of the group may not have permission to approve the merge request as they do not have access to it.
For example:
In the group structure below, project 1 belongs to subgroup 1 and subgroup 4 has users.
Project 1 has configured an approval rule for the project, which assigns subgroup 4 as approvers.
When a merge request is created, approvers from subgroup 4 appear in the eligible approvers list.
However, as users from subgroup 4 do not have permission to view the merge request, the 404 error is returned.
To grant membership, the group must be invited as a project member. It is now possible for users from subgroup 4 to approve.