Require multiple approvals per CODEOWNER Section
This adds an option to specify more than one user to be required for approvals. So that is multiple approvers out of one pool of approvers (i.e. all approvers are equal). Until this is released, GitLab considers a CODEOWNER rule satisfied if one user has approved who is on that rule. This will enable multiple CODEOWNER approvals.
You can now precisely define for which files, file types, or directories you make approval optional, require approval by 1 user or by multiple users. The latter being the new improvement of CODEOWNERS.
So far, if you needed to require multiple approvers be it for compliance reasons or other reasons, you could only do so with an approval rule. However, unlike CODEOWNER approvals, approval rules apply to entire branches and cannot be refined to apply to specific parts of your code base. So, the multiple approvals would have also been required for changes that do not need a high level of scrutiny leading to unnecessary reviews.
Problem to Solve
CODEOWNER approvals for protected branches allow organizations to ensure that code is reviewed and approved by appropriate subject matter experts. However, It's not possible to require multiple approvals for a single rule (like you might do with peer and then maintainer approval).
CODEOWNERS should allow an option that supports specifying the number of members of each CODEOWNER section that are required to approve to satisfy the CODEOWNER rule.
One way that might be easy to do this (if decided) is by supporting a number in a second bracket next to the section:
[SECTION][#] README.md @group
In the MR UI the number of required approvers would be shown accordingly (in the example image it would be 2 for the
In that example
# could be
2 or something and then that rule would parse out to requiring two approvals to satisfy that section.
The following shows the two use cases raised in comments on this issue here. Note: describing these use cases is not very easy so that it could be that some commenters actually belong in the other group than I put them.
|require approval from multiple approvers out of one pool of approvers (i.e. all approvers are equal)||require approval from multiple sets of approvers (e.g. 1 approval from the pool of engineers and 1 approval from the pool product managers)|
|insurance company||internal note from customer from which it is very clear that they want this use case|
|Internal note from customer but it is not very sure they belong into this use case||#335451 (comment 1015757622)|
|internal note from customer; it is likely that they need this use case||#335451 (comment 1127674444)|
|#335451 (comment 770259726)|
|Fortinet could migrate over from Reviewboard if this was enabled|
Unclear which use case these belong to:
Level of control
Beyond these use cases, there is also the question of the level of control.
|rule level||section level|
|#335451 (comment 1067911835)||#335451 (comment 621000479)|
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.