CODEOWNERS per branch

Can you provide some link to that “other discussion board” as I am also interested to be able to have different reviewers for different branches. I cannot find that answer.

This topic is already on “the other board”, How to use Git and GitHub. It was moved, not copied :grinning:

Apologies that this seems to have not gotten answered when it was originally posted. The contents of the CODEOWNERS file on the branch in question governs the behavior of the feature for that branch. So if CODEOWNERS says one thing on master and dev but something else on test then the feature will follow the first set of rules for PRs to be merged into master or merged into dev but follow the different rules for PRs to be merged into test.

I hope that helps!

1 Like

I seem to be maybe missing something or maybe just need a clarification. Does the CODEOWNERS file apply to repo owners/admins?

Reason I ask is because in my repository I have a master and a dev branch and set it up as suggested in this thread. Both branches have the CODEOWNERS file in a /.github directory. In the master branch codeowners file I but my user id as the only review using the ‘*’ syntax (e.g. “*   @aspea002”). Had a colleague of mine test it out by opening a PR between master(base) and dev and my name shows up in the reviewers section. So to test things out further I then created/updated the dev branch with its own CODEOWNERS file contents to have it reference my colleagues ID. I then tried opening a PR with a dev2 branch against dev(master) however I do not see his name being added to the Reviewers section. I do so for a brief moment the words “Loading reviewers…” but then it just stops and shows “No Reviewers-select one”.

As I mentioned earlier, is this because I am a repo admin. I have tried different settings on the DEV branch everything from not having the DEV protected branch setting turned on to adding the protected branch settings with combinations of requiring a reviewer and codeowner review required and nothing has changed. Also forgot to mention this is all done with my colleague permission on the repo set to WRITE.

Any help would be appreciated.

Hi @prowler0305,

The CODEOWNERS file should apply to all users with write permissions. Is the repo you’re working in public by chance? If so, could you share a link to it so we can look closer? If it’s a private repo, I’d recommend working with private support for a solution.

1 Like

I am looking at using CODEOWNERS as part of a project with a large number of developers.    I want to implement a separate review policy for “master” and “develop” branches.      I understand how to set this up initially, but I don’t understand how one  prevents subsequent merges from blending the two policies.    Some manual experiments on a toy repository show that  a merge from develop to master updates the CODEOWNERS policy on master and therefore undoes the intended policy there.

Is this just something that I should “not want to do”?    It seems like such a nice approach otherwise.   But the dearth of similar questions being asked on this topic suggests I’m alone in really wanting to exploit the per-branch aspect of this feature.

5 Likes

Not clear to me either how to prevent merges between branches overweite the CODEOWNERS file

Do we need to put it in .gitignore and change it manually ?

1 Like

Hi @mderazon,

Merging a branch into master overwrites the CODEOWNERS rules for master. This is the expected behavior. [git merge](https://git-scm.com/docs/git-merge#_description) takes all the changes that were made to the source branch since the source and destination diverged and applies them to the destination branch. So if CODEOWNERS changes on the source branch, that change will be applied to the destination branch when they are merged.

There are multiple ways this could be managed:

  • Instead of merging, one could cherry pick only the changes that do not touch CODEOWNERS
  • One could create a merge script that would do the merge and then reset CODEOWNERS to a known-good state

Hope this is helpful. 

1 Like

I understand. It’s not very convenient however :-/

Also, the docs are very vague about it

3 Likes

Hi @mderazon

Thank you for the feedback. I have shared with the appropriate teams for consideration.

Please let me know if you have any other questions.

Cheers!

+1 on this… it would be great to have such functionality, i.e. different teams of codeowners for different branches, resulting in a separation between development and production branches… Forking could have been another way, but not possible when have to use the same account… Wish there was a .(git)branch folder to keep such branch specific settings. Currently, although a great feature, it is a tradeoff between QA and creating PR bottlenecks.

3 Likes

Is there any other way to protect CODEOWNERS file being merged? Adding CODEOWNERS in .gitignore disables the CODEOWNERS, so this option is not working.

Hey @shubhra27,

Thanks for your input here, due to the way CODEOWNERS and Branch Protection function, there currently isn’t a way to do that built-in to the CODEOWNERS feature. 

That being said, it would be super great for us if syntax could be expanded so that we can specify which branch the rule applies to in the code-owner files.

6 Likes

As a future improvement, it would be really nice if the branch owner logic could live in the CODEOWNERS file itself. Having a file exists in two different states across branches prevents normal merges and is awkward to maintain.

8 Likes

We are also looking for a feature so that we can define codeowners file in GitHub to have rules per specific branch, so that the same file can exist across all branches but apply its rules for the protected branch depending on what branch that is. Please let us know if GitHub has an open issue for this that we can watch or vote or has this not even been logged in.

The same idea as these previous messages, i was curious about this:

If i put a CODEOWNERS file in ./.github that has some rules

but then put another CODEOWNERS file in the / root, will it obey both?

That way we could have a sort of “global” list, and then a more ephemeral version that people can change during each PR/Branch/etc

Add the CODEOWNERS file to your  .gitignore file  in ALL your branches then modify each branch with respective codeowners you want  (ex. prod branch with OPS codeowners/approvers & dev branch with dev codeowners/approvers) or leave it blank if that branch doesn’t need codeowners. this will prevent overwrite on merge (there may be additional setting you need to enable like branch protection and you may have issues if you’re an admin but i tried this and it seems to work on my repo – i have an admin user and a regular contributer user )

This doesn’t work because CODEOWNERS needs to be one the remote repo. In your exemple, it is only on the local one

This answer “works”, but seems to miss the point that cherry-picking is a work-around for an entirely predictable problem.  Furthermore, and more importantly, it is _not_ a set a forget work-around… it needs to be trained and institutionalized across the team such that it is execute for every PR!

CODEOWNERS is designed to be specific to a branch (and for good reason). Since CODOWNERS is supposed to be branch specific, it is designed such that only on exception would a team would want it to be merged into the base branch. The issue of course is that if you do have different CODEOWNERS on the base and compare branches, everytime a pull request is issued it will queue a generally unwanted merge of the CODEOWNERS files.  This answer suggests that we actively prevent this entirely expected problem from happening on each and every pull request. Since both pull requests and CODEOWNERS are GitHub additions to git (bravo) and that pull requests are a core feature of GitHub that existed before the addition of the CODEOWNERS feature,  it is hard for me to understand why the pull request feature was not amended to ignore the CODEOWNERS file by default. 

Is there a set-and-forget work around for this?  I am experimenting with .gitignore, but so far it is not a great solution.