Multiple blocking merge request approval rules

Some organizations require all changes to be reviewed and approved by specific groups of people before a change can be merged (e.g. every change must be approved by at least: 1 staff engineer, 1 product manager, 1 production engineer). GitLab only supports selecting users (and groups) who can approve the change and a minimum number of approvals required. In this structure it is impossible to enforce the sign off structure in the example above.

This feature is supported by Phabricator by being able to mark a reviewer as "blocking" and is also supported by BitBucket. GitLab should support blocking approver groups so that organizations can be sure the right people review each change.

Original description

We currently use phabricator for our code reviews, and one of the more useful features it has is the ability to mark a reviewer as "blocking", meaning the change is not ready to be released until that specific person approves it. This is extremely important and useful to us, because our release workflow for one of our products requires changes to be signed off on by at least one person from two or more groups. Gitlab supports approval groups now, but no way to add multiple groups to a review; nor does it have the ability to mark a reviewer as blocking.

The proposal to add blocking comments kinda would work for this, but honestly, it's not an ideal solution.

Proposal

Extend the approval model to support multiple rules, where a project may have n rules, where a rule is:

• a list of users and groups – \mathbb{R}_{a} is the set of explicit approvers for rule a
• a minimum number of approvals — m_{a} is the number of required approvers for rule a

Each eligible approver who approves the merge request approves the merge request in it's entirety. That is, approvers do not check off each rule one by one, instead they approve the merge request as a whole. This means: when a person who is an eligible approver for multiple approval rules, approves the merge request, their approval will be counted towards each approval rule for which they are an eligible approver. Removing their approval of the merge request will remove their approval from every approval rule.

This will allow the following new behaviors:

• individual approvals to be required (Approval from @user required) by creating an approval rule with one user and required approval count of one.
• group approvals to be required (At least n approvals from @group members required) by creating an approval rule with one group and an approval count of n

Configurations:

• zero approval rules (Starter, Premium)
• one approval rule (Starter, Premium)
• multiple approval rules (Premium)

Interactions with existing features:

• Override approvers and approvals required per merge request

  If enabled the list of approvers and approvals required in an approval rule may be modified.

  Removing approval rules per merge request is not allowed. Project approval rules can be nullified by reducing the approvals required to zero. Required approval counts can only be increased, but not decreased.

  Adding approval rules per merge request is out of scope for this iteration.

• Enable self approval of merge requests

  Self approval should continue to function as is.

  If the project approval rules include the merge request author, they will automatically be an eligible approver for one or more rules.

  If the project approval rules do not include the merge request author, they will not be eligible unless added to a merge request approval rule subject to the override approvers feature being enabled.

• Additional approvals once approvals required have been met

  This should be reworded 'Additional approvals once all approvals required have been met'

Design

Project Settings

Empty	GitLab Premium	GitLab Starter

Expanded	Confirm Delete	Mobile

All approvals related project settings have been moved to a separate section under Project Settings → General → Merge request approvals.

Add/Modify approvers

Add	Modify	Undo removal	Mobile

Merge request create/edit form

Desktop	Mobile

Only the number of approvals required is editable on project-level approval groups. If "Override approvers and approvals required per merge request" is enabled, the MR author can add additional approval groups from the MR create/edit form.

MR widget

Ideal	Mobile

Expanded	Mobile

Only one (without name)	User cannot approve	Approve additionally	Revoke approval

• In all the MR widget cases, a maximum of 5 approver avatars is displayed in the collapsed state of the widget. These 5 approvers are considered the best approvers meaning they are in more than one approver group and so there is a greater chance of getting the MR fully approved by them.
• Approver groups (in the table) and approver (in the avatar rosters) are listed in alphabetical order.

💎 Design specs →

What does success look like, and how can we measure that?

This feature has been prioritized on that basis that customers require greater granularity for meeting their approval requirements, and to enable granular code ownership approvals.

This can be validated by measuring the number of projects with multiple required approval rules, multiple_approval_rules

Links / references

Kinda describes Phabricator's approach