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

• Problem to solve
• Proposal
  • Scenario illustration
• Implementation Plan
• Further details
• Out of scope
• What is the type of buyer?
• Open Questions

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.

Scenario illustration

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

Open Figma →

Implementation Plan

frontend - 3️⃣

1. Update the UI text for all instances of Any eligible user and Any branch as they are used by the same components across the product
   1. Double-check the documentation for the areas using these UI components to see if screenshots/descriptions need updating too
   2. Any branch rename was done in Replace "Any branch" with "All branches" (!70552 - merged)
2. Add a new selectable option in the branches dropdown for all protected branches only for projects level
3. Update the forms store to handle the new option and submit it to the backend correctly for saving
4. Update the approval rule list to show all protected branches
5. Update/add specs

Further details

Background evidence around the problem space

• &4367 (comment 619317599)
• &4367 (comment 620116744)

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.