<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=389474) </details> <!--IssueSummary end--> <!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### 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. --> For [group-level default branch protection settings](https://docs.gitlab.com/ee/user/project/repository/branches/default.html#group-level-default-branch-protection): add options for the setting to cascade down to all 1) existing, and 2) future subgroups and projects. #### Current behavior on GitLab.com - Default branch protection settings on a group only apply to direct repositories in that group, and only to repositories created after the setting has been updated. - To make the setting consistent across all existing subgroups and projects, you have to manually change the setting on each subgroup/project, one-by-one - Regardless of the default branch protection setting on a parent group, newly created subgroups are always set to `Fully protected`. #### Current behavior on self-managed Admins of self-managed instance can control [instance-level default branch protection settings](https://docs.gitlab.com/ee/user/project/repository/branches/default.html#instance-level-default-branch-protection), and can choose whether to allow group owners to [override the setting](https://docs.gitlab.com/ee/user/project/repository/branches/default.html#prevent-overrides-of-default-branch-protection) for their group. But, this only partially resolves the problem: group owners on self-managed instance still can't choose to propagate their default branch protection setting to their subgroups or projects. #### Desired Behavior - Group and subgroup owners can choose to propagate the default branch protection setting to: - new subgroups and projects - existing subgroups and projects - Group and subgroup owners can choose whether these cascading settings are enforced or can be overridden. ### Problem to solve <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> 1. When a customer wants to change their default branch protections on *existing* groups/subgroups and projects, they either need to go one-by-one in the UI or write a custom script to update the setting in each subgroup and project. 2. When a customer wants a consistent default branch protection setting on any *new* subgroups, they have to implement a clunky workaround (for example, setting up a [subgroup events webhook](https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html#subgroup-events) that triggers a pipeline which updates the default branch protection setting). Both of these limitations result in a tedious and time-consuming process, and it doesn't provide a good user experience. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. --> 1. SaaS customers who want to establish and/or enforce a consistent workflow across *all* of their projects 2. Self-managed and SaaS customer who want to establish and/or enforce on *a subset* of their groups/subgroups and projects. ### Related epics and issues <!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section. --> - [Settings Management for Organization, Group and Project levels](https://gitlab.com/groups/gitlab-org/-/epics/4419) (epic) - [Cascading pattern for settings](https://gitlab.com/groups/gitlab-org/-/epics/9282) (epic) ### Questions - Should this be split into multiple feature requests? 1. Apply the group-level default branch protection setting to *existing* subgroups and projects 2. Create option in SaaS to *enforce* group-level default branch protection setting 3. Cascade group-level default branch protection setting to all future subgroups and projects <!-- Label reminders Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ -->