### 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)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#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. ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### Links / references