**Rollout is ongoing:** Please provide any feedback in the https://gitlab.com/gitlab-org/gitlab/-/issues/486050+ --- ### Problem to solve GitLab offers a number of controls that can be implemented as safeguards. These controls such as protected branches, approval rules, code owners approvals, and many more can be put in place to enforce adherence to policies that ensure quality. A recent SUS study and other feedback suggest that users struggle to find the different controls and struggle to understand which settings interact how. [Framework for Source Code Rules](https://gitlab.com/groups/gitlab-org/-/epics/6351) aims at making it easier and more intuitive to administer your Source Code management tool. **This MVC is the second iteration of Source Code Rules that makes the different rules _editable_ in one single place and will organize them on a per-branch basis. Viewing is not part of this epic. It is part of the first iteration which is in https://gitlab.com/groups/gitlab-org/-/epics/8578+.** This MVC is the first iteration of Source Code Rules that is bringing the different controls together into one single place and will organize them on a per-branch basis. ### Release post _Suggestion: as it is very unlikely that we can resolve all child issues within one single release, we should send out multiple release posts. One with each iteration. An iteration would typically be that we added editing for one type of setting, e.g. editing protected branches or editing approval rules. The following is therefore not a real release post but one that binds multiple posts together._ You now edit settings for protected branches and merge request approvals conveniently in one single place under **Settings > Repository > Branch rules**. Moreover, as the name suggests, they are now viewed through the lens of a branch as they naturally relate to such. While no functionality is changed this significantly improves discoverability and intelligibility of your settings. Previously, these settings were in far apart places making them hard to understand as we learned from user feedback including a recent SUS study. Next we intend to also [move security approvals under branch rules](https://gitlab.com/gitlab-org/gitlab/-/issues/368467). Long-term we will consider moving also setting under branch rules that currently don't relate to branches but might benefit from attaching them to branches such as status checks or merge checks [Framework for source code rules](https://gitlab.com/groups/gitlab-org/-/epics/6351). ### Proposal Based on the results of https://gitlab.com/gitlab-org/gitlab/-/issues/342086 it has been determined we should organize rules based on branches. While still potentially complex, this issue represents the "boring" solution of applying that organizational system while applying current feature functionality and UI where possible. Add section `Branch rules` after section `Default branch` (Settings > Repository Settings > Branch rules) ### Designs :tv: [Design walkthrough](https://youtu.be/52bUdcX_yRk) [Figma designs](https://www.figma.com/file/eq2nf3B8MhB9xKrC0VzbPf/Repository?type=design&node-id=916%3A2969&mode=design&t=zrP2cLygKOMQqcde-1) - Dec 5: Relabelled `Target branch` to `Rule target` - This label allows the functionality to work whether it is a all branches, all protected branches, name, or wildcard. - This label change is also necessary in case it might be clash with "Target branch" from merging branches https://gitlab.com/gitlab-org/gitlab/-/merge_requests/130548 https://gitlab.com/gitlab-org/gitlab/-/issues/17909#note_1634018985 ### Implementation Plan #### Updated after the sub-epic breakdown (Jan 25th, 2024) - [x] 1. [Handle the create, edit and delete operations for a Branch Rule](https://gitlab.com/groups/gitlab-org/-/epics/12525) (epic) - [x] 2. [Handle "All branches" and "All protected branches"](https://gitlab.com/gitlab-org/gitlab/-/issues/388129) (issue) - [x] 3. [Implement the ability to add Merge Request approvals inside Branch Rules](https://gitlab.com/groups/gitlab-org/-/epics/12523) (epic) - [x] 4. [Implement the ability to add branch Protections](https://gitlab.com/groups/gitlab-org/-/epics/12524) (epic) - [x] 5. [Implement Status checks in Branch Rules](https://gitlab.com/groups/gitlab-org/-/epics/12522) (epic) You can still review the previously used implementation plan below. <details><summary>Outdated implementation plan</summary> - [ ] 1. https://gitlab.com/gitlab-org/gitlab/-/issues/388128+ `1:36` in the [Design walkthrough video](https://youtu.be/52bUdcX_yRk) - [ ] 2. https://gitlab.com/gitlab-org/gitlab/-/issues/388129+ - [ ] 3. https://gitlab.com/gitlab-org/gitlab/-/issues/362212+ - [ ] 4. https://gitlab.com/gitlab-org/gitlab/-/issues/362214+ - [ ] 5. https://gitlab.com/gitlab-org/gitlab/-/issues/388130+ - [ ] 6. https://gitlab.com/gitlab-org/gitlab/-/issues/362218+ - [ ] 7. Toast alerts on updates https://gitlab.com/gitlab-org/gitlab/-/issues/19572+ </details> <details> <summary>Diagrams</summary> | header | header | | ------ | ------ | | Default - Initial |  | | Branch rule filled out |  | | Editing with drawers |  | | Use of toasts on updates |  | | Modals for delete confirmation |  | </details> ### Related links Analytics issue relating to this work: https://gitlab.com/gitlab-data/product-analytics/-/issues/716+ <!-- 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 -->