Designate optional sections in the codeowners file
Problem to solve
With code owners sections, all code owner rules must be enforced or none. This means that if there are important compliance rules that must be enforced, every rule must be enforced. This means another team that simply wants to be notified and added as optional approvers of relevant merge requests must forgo using code owners or become a required approver.
Currently we handle the requiring of code owner approval through the protected branch POST (create) endpoint here.
Proposal
Specify optional rules in the code owners file
Use declarative nomenclature before a rule to mark it as optional, for example ^
.
Foe example in the following file, the Database
section would not be enforced as it has been denoted as optional
[Documentation]
ee/docs @gl-docs
docs @gl-docs
^[Database]
README.md @gl-database
model/db @gl-database
For duplicated sections and rules, the most restrictive should always win.
Prior proposal (for ref only): Allow users to select a code owners section as an approval rule for newly protected branches.
Acceptance Criteria:
- We can create a new protected branch with selected sections
- When we create a new protected branch, we sync the approval rules
Note Make sure to use Gitlab::CodeOwners.sections
to fetch available sections
Feature flag
optional_code_owners_sections
Release notes
Code owners sections allow each team to configure their own code owners entries independently. The section rules may be used for shared paths so that multiple teams can be added as reviewers. However, all code owner sections must be enforced or none. For example, if there are important compliance rules that must be enforced, every rule must be enforced. This means another team that simply wants to be added as optional approvers of relevant merge requests must forgo using code owners or become a required approver.
GitLab 13.8 introduces the ability to designate optional sections in your code owners file. Simply prepend the section name with the caret ^
character and the section will be treated as optional. This means, related change through merge requests will not require approval from designated owners. With optional sections you may continue to designate responsible parties for various parts of the code while providing a more relaxed policy for parts of your project that may be updated often but don't require stringent reviews.