Skip to content

[Backend] Allow "all protected branches" for MR approval rules in projects

Problem to solve

Users want to ensure proper separation of duties using merge request approvers in their projects for specific branches. Today they do this by manually entering approval settings for individual branches. This is very time consuming and error prone, especially if a project has dozens of protected branches or when the protected branches changes.

Proposal

Allow users to define an approval rule they would like to use for all protected branches in a project. Add a new option, All protected branches, to merge request approval rules at the project level.

While also replacing Any eligible user → All eligible users and Any branch → All branches to keep consistent UI text

Automatically apply this approval setting to any branches that become protected, even if they were not originally.

Implementation Proposal

  • Add a new database column applies_to_all_protected_branches:boolean (or perhaps something less... verbose)
  • Alter the logic of def applies_to_branch?(branch) to return true if applies_to_all_protected_branches is true and branch is a protected branch of the appropriate project.
  • Add the new parameter to the /api/v4/projects/23/approval_settings/rules REST endpoint to allow for read/write of the new parameter.
  • Update REST and GraphQL APIs to output a dynamic list of all protected branches in the protected_branches key in API responses.
  • Should be implemented behind a feature flag

Scenario illustration

A merge request approval rule "Villains" targets All protected branches

Branch_update

Open Figma →

Further details

Background evidence around the problem space

Out of scope

Group and subgroup implementation

  • This proposal will set the foundation to create a useful generic rule that could be scaled to the group level in the future.
  • Future issues/epics will cover group and subgroup

What is the type of buyer?

GitLab Premium

Open Questions

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 Robert Hunt