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.
+1 on this feature.
Having CODEOWNERS at each branch level reduces the risk of someone without permission (developer) to accept changes on other branch (release). Instead of having CODEOWNERS only at the repository level, having the ability to have CODEOWNERS for each branch enforces the GitFlow.
Hi I am now also facing this problem. Please consider adding the ability to specify a branch pattern in the CODEOWNERS file.
+1 for this feature. we established the process and the ability to configure different code owners per branch type (name wildcard) would be really awesome
+1 also on this feature. We are using codeowners in our company but are now struggling with the problem that lots of people are unnecessarily being asked to review PRs that are on integration branches. Please please support a viable work around. Cherry picking is not a practical solution for us.
Hi all, We have faced the same concern and found a simple work around.
Normally, repositories have a direction were code propagates to, ideally being master the target branch and a ground point would be a feature branch or dev branch. If you align CODEOWNER file with this stream you will suffer the known issue. If you reverse the flow you will end up having different versions on each branch, if you want, without risk of overwrite.
Once your file goes from ground to target, all branches will be aligned, then You can reverse the flow for this file: you just need the base branch one commit ahead of your source branch this commit is the CODEOWNER update, since the source branch has all commits from base, the difference on base won’t be overwritten.
- setup file for dev branch
- propagate to release (or next upper branch) your release is now overwritten
- update release with file version for the branch, this will place release one commit ahead
- iterate to next upper branch.
Now new PR won’t modify the CODEOWNER file
However, in some situations we might want to merge release branch onto develop for isntance, this would create an issue
+1 for specifying which branch(es) the code owner rules apply to with the CODEOWNERS file
+1 Need this feature. Will be much easier to manage PR’s .