### Problem to solve <!-- What is the user problem you are trying to solve with this issue? --> Users want to be able to have standardized workflows across teams and projects and leverage protected branches as a way to do this. Today, they must manually set a protected branch up for each project. This is error prone, time consuming, and means individual project owners can change the rules if they wanted to. This last point is especially important because these protected branches are used to enforce compliance requirements that the organization has. ### Proposal <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> 1. Provide a group-level setting to specify a string for a protected branch that will apply to all projects within the group. * The string may include wildcard globbing (i.e. `projects-*`) or may not * Once set, do not allow individual projects to change or delete the group-level rule. Show it as locked / enforced. * Leverage and copy the existing project-level protected branch experience as much as possible to remain consistent within the different screens in the product. * **Exception:** The group-level branch input should be a simple text input for the first iteration. * <details><summary>Existing project approach</summary>  </details> 2. When set, any branch in a child project with a name that matches the string or wildcard string should be protected. * As an example, a group may set a protected branch wildcard string for `prod*`. If a child project has a branch called `production-branch`, it should be protected. * In the case where the string does not match any projects, do not throw an error. The branch help text should read `Branch does not exist`. The user is expected to put the correct name in for this rule, which may be for future, not-yet-created branches. #### Excluded from proposal Some items to intentionally exclude from this first iteration are below. They could be considered for follow-on iterations if needed: 1. Selecting existing project branch names 1. Specifying only some of the projects in the group to be protected * This was excluded from the first iteration because is introduces a lot of complicated edge cases to address. 1. When a wildcard has been specified, provide a way to list all the protected branches that match the given rule. * Consider using the existing approach that projects use. * This requirement is a large scope, so moving it to a subsequent issue. * <details><summary>Existing project approach</summary>  </details> 1. Being able to set the protected branches on a subgroup. This iteration is intended to only focus on adding protected branches at the top-level group. Future iterations can bring this to sub-groups. ## UX Group-level view:  Project-level view with inherited group-level protected branches:  **Additions:** - Adding a new «Protected branches» section to `/-/settings/repository` group settings (like we have in projects) - Exchange branch select with an input field for MVC as we'll only support wildcard branches - Adjust description of branch field to include the word «Only» ## Relevant links ## Non-functional requirements - [ ] Documentation: Document how to manage group-level protected branches + screenshots - [ ] Feature flag: `group_protected_branches` - [ ] Performance: - [ ] Testing: ## Implementation plan <details><summary>Old implementation plan from 2020, consider using it as a reference but it most likely needs to be updated to match the changes to the codebase & the requirements above.</summary> - [ ] gitlab~3098698 Add a new `namespace_id` (`big_int`) column on `protected_branches` table ```plantuml hide circle skinparam linetype ortho skinparam shadowing false entity "namespaces" as e01 #e9f3fc { *id : int } entity "projects" as e03 { *id : int } entity "protected_branches" as e02 { *id : int -- project_id : int namespace_id : bigint code_owner_approval_required: boolean } e01 ||--|{ e02 e03 ||--|{ e02 ``` - [ ] gitlab~2492649 Introduce group-level protected branches GraphQL for mutations * `createProtectedBranches` * `updateProtectedBranches` * `destroyProtectedBranches` - [ ] gitlab~2492649 Query group-level protected branches (GraphQL or standard controller) - [ ] gitlab~3412464 Add `Protected Branches` to `Repository` settings in Group views * Reuse the existing HAML template `ee/app/views/projects/protected_branches/ee/_branches_list.html.haml` * When a rule is inherited & enforced disable the row inputs and replace the unprotect button with a lock icon. </details> 1. gitlab~3098698 :two: https://gitlab.com/gitlab-org/gitlab/-/issues/372815+ 2. gitlab~2492649 :five: https://gitlab.com/gitlab-org/gitlab/-/issues/372816+ 3. gitlab~3412464 :two: https://gitlab.com/gitlab-org/gitlab/-/issues/372817+ 4. gitlab~3412464 :two: https://gitlab.com/gitlab-org/gitlab/-/issues/372818+ 5. gitlab~3412464 :three: https://gitlab.com/gitlab-org/gitlab/-/issues/372819+ #### To solve: - How should the inherited protected branches be shown in protected branches dropdown lists? I.e. approval rules, status checks, and the policy rules builder all make use of protected branches selection. - Other things using protected branches to run which we need to make sure work with the group-level inheritance: - CI pipelines - CI variables and secrets - Runners - Deletion protection - Audit events - Deploy keys - MR reviews - DAST - Project mirroring <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->