Allow group-level MR approval rules for 'All Protected Branches'

Release notes

Problem to solve

Compliance minded organizations wish to ensure that all code in MRs reaching their production environments goes through specific approval workflows. They can do this today with MR approval rules at the project-level. The problem with this approach is that it does not scale for larger teams and also can be changed inappropriately by project members. Compliance teams have to manually update each and every project to have the proper rules and then must monitor them to ensure that none have been changed inappropriately.

Proposal

Allow a merge request approval rule to be created at the group-level which will then cascade down and be enforced on sub-groups and child projects.

  • If a rule has been set at the group-level in this way, do not allow it to be changed or edited at the sub-group or project level.
    • These rules should be able to be created at both the root group and the sub-group level. They should each behave the same way.
    • Rules set in a group should appear and also be locked in any of their child sub-groups as well as projects within those sub-groups.
  • Only allow for All protected branches or for a wildcard to be specified for the branch name. We intentionally do not want to allow for All branches since it would be overly inclusive and effect every change in GitLab, which is not what users will want since it would then affect every one of their users.

Scope

  • Add a component at the Group level to capture group-level MR approval rules
  • Group level rules replace project level rules and the existing project-level component is inactive
    • There is a message saying why they are inactive
  • Project level rules are active if the are no group level rules
  • Assuming a single level of inheritance Group -> Project only in this iteration
    • Will not support Group -> Group -> Project in this iteration
    • This was not discussed on the call
  • Project designs to be re-worked as this will be delivered prior to Edit Branch Rules is delivered @mle
  • All iterative work will be hidden behind Feature Flags until the whole piece is completed.

Implementation approach

To be discussed further with BE engineers @jwoodwardgl and @ghinfey today, but assuming this can be promoted to an Epic with 5 sub-issues attached:

  1. Model layer for group-level MR approval rules backend
  2. API endpoints for group-level MR approval rules backend
  3. Add FE components for group-level MR approval rules frontend
  4. Inherit rules from Group level to Project level frontend backend
  5. Project level MR approval rules UI changes frontend

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.

Edited by Sean Carroll