Approvers management - adding CODEOWNER rules by branch
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
Allow for branch specific syntax/sections within CODEOWNERS.
Customer is looking to restrict / tune merging activity across branches. They have landed on using CODEOWNERS, which doesn't currently support any syntax to apply rules specifically to branches.
Creating on behalf of the customer from ZD Internal.
Environment/Use case Context:
Gitlab is LDAP integrated, and team group access is managed by AD groups. But managing approvers for merge requests has to be done at the project level – this doesn’t support AD groups like the Gitlab Group access does, but it does support Codeowners files. That’s how we landed on Codeowners.
- Teams need to be able to restrict merging activity across branches
** Developers on this team are >30 users, some senior and some junior ** Development branch approvers are a subset of the total (more senior members of the team), ~20 users ** QA branch approvers is an even smaller subset of the total (team leads), ~6 users
Workflow / Workarounds
- At the moment, the only workaround seems to be “different codeowners files per branch” which seems cumbersome to manage when merging.
- Previously, we were using the dropdown feature to manually add approvers via the UI on the branch protection settings – the problem with this is that AD groups are not an option, so we have to select each user individually rather than selecting an AD group.
Proposal
So – the solution could be “more granular user access permissions in the Gitlab role settings”, which it seems like are in the works, but I’ve no idea if limiting merge request access is an option between member users of a project.
Or, it could be making Codeowners files work with different branches (i.e. making specific headers or something that indicate which branch the rules should apply to rather than using different codeowners files in each branch).
Another thought in addition to the above options would be making approvers manageable at the group level for all child projects – this specific team has 20+ projects in their Group, and they need these approval rules to apply to all of them.