Scoping CODEOWNERS to a set of branches
Problem to solve
In my company we use a branching process based off of this model: http://nvie.com/posts/a-successful-git-branching-model/
This means we have a set of core branches that we protect and build off of. And many, many feature/bug-fix/personal branches where work happens, before being merged into one of the core branches.
We also use CODEOWNERS to add an additional layer of review to select files in our repo.
For every MR in our repo, for the core branches, as well as every feature/bug-fix/personal branch, when one of the CODEOWNERS defined files is modified an additional review is needed. And this happens a lot. Dozens of times a day. We really don't want to review those changes on feature/bug-fix/personal branches. We only really want to review those changes when they are complete and are in a MR to our core branches. There is no configuration in CODEOWNERS that allows us to do this. It's all or nothing.
Intended users
In our development environment the following personas will update the CODEOWNERS defined files and/or be one of the reviewers of the files defined in the CODEOWNERS file.
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sam (Security Analyst)
Further details
Our main uses of the CODEOWNERS file involve Security checks on sensitive files, and validation of correctness on complex parts of our infrastructure. The reviewers are SMEs who provide approval and guidance to developers across our company.
Proposal
We would like the ability to scope a CODEOWNERS file config to a branch or set of branches. So that additional approvals are only needed when a MR is on one of those branches. For example, adding a list of branches after the existing config on each line.
package-lock.json @npm-lockfile-reviewers 'develop release master'
A possible alternative is a more global setting that would apply to all configs in the file. Perhaps a line like the following at the top of the file?
BRANCHES: develop release master
Some scenarios...
Developer A creates a feature branch off of our core "develop" branch. Developer A modifies a file defined in the CODEOWNERS file. Developer A merges her branch into a team mates feature branch, creating a MR. Reviewer X needs to review and approve that MR because there is no way to scope the CODEOWNERS config to a set of branches. Reviewer X is sad because they are reviewing non-valuable merges all day.
Instead...
Reviewer X updates the CODEOWNERS file config for a protected file, with a list of branches. In our case; "develop, release, master". Developer A creates feature branches and modifies files in the CODEOWNERS file. Merges branches to other feature branches and does a lot of development goodness. All without needing a review/approval. Developer A is done with her development and wants to merge into our core "develop" branch and creates an MR. Reviewer X is asked to review the change because the file(s) changes are in the CODEOWNERS file config and the MR is against one of the specified branches. Reviewer X is happy do to the review because it's a high value exercise done only when it's needed.
Success!!!
Permissions and Security
No changes to permissions are envisioned. Existing CODEOWNERS permissions/security should suffice.
Documentation
Documentation changes to how CODEOWNERS file config and usage.