Allow code owners to review their own PRs

[frans-k]

We have these boxes checked in a branch protection rule:

• Require approvals
• Require review from Code Owners

I would like to check this box:

• Include administrators

To include admins in other branch protection rules, like waiting for actions, but that would also mean that admins would have to have their PRs approved by another code owner, which just isn't feasible for our setup. We also have some solo code owners.

Something along the lines of code owners approving their own PRs would solve this, which I've seen that Azure has in other discussions about this topic.

[mve-oncomfort]

I agree this is very useful to have for very small teams

[fernandomora]

Users have been asking for this since Nov 2017: https://github.community/t/do-not-require-owner-approval-if-the-pull-request-is-from-an-owner/369
We have a repository where different teams are owning different folders.
We want to explicitly approve PRs by the teams owning the folders.
But if there is a team that is composed by a single user, there is no possible way to merge if that user sends a PR.

Also, we have a automated action, that sends a PR and approves it to be merged. We needed to create 2 different bot user accounts for being able to make the workflow work, because the bot needs to belong to the CODEOWNERS team of the folder that is sending the PR, but another different bot needs to aprove since users cannot approve their own PRs

[OmgImAlexis]

Just to note that link won't work anymore since Github replaced their forums with Github discissions.

Also wayback machine won't work since it only saved the first few messages. 🙃

https://web.archive.org/web/20210920224702/https://github.community/t/do-not-require-owner-approval-if-the-pull-request-is-from-an-owner/369/1

[tt-rkim]

+1

Has there been any movement on this? If there two codeowners on a group of files and one's on vacation, the other one is screwed.

[teaf-wise]

Going through the same pain points described above, would be great to see some action on this

[mrr11k]

Same here. It would help us a lot, if we get this feature. 🙏

[BlueGi0]

+10000
We have Different repos owned by:

• "Devs-Team": Several Devs (Write Privileges + branch protection rules for merge on specific branches)
• "TL-Team": Technical Leader (Mantain Privileges + "Enable auto assignment" Permissions for Code Review)

So for each PR, the Techical Leader can Make de Code Review and aprobe PR's for production. But for example, in the case of an incident outside of working hours where he could make a Hot Fix, he cant't aprobe his own Pull Request.
It would be very nice to have a way to make it happen.

[pascalguttmann]

I agree. For our small team that missing functionality is a problem. Being able to approve your own PRs would be a solution.

Is there a lightweight workaround known at the moment?
Maybe it is needed to switch to a different solution like GitLab, Gitea, etc...

[LMSSonos]

My solution is to go into settings, change the branch protection and remove the required users - once the PR is passed, i add it again. Only issues, if other PRs are ready to merge but not reviewed, they will also merge. so more a hack than a solution ;-)

[gtomitsuka]

+1
Any activity on this?

[hanna-seraya]

+1 We also have a singe codeowner model, missing of this functionality lead us to always open to merge-for-everyone repo and a lot of disputes after merge. Creating "duplicated" user is not a choice for our organization, this way everyone should have duplicate

[BillPruettZen]

Please do this

[inickles]

It looks like a reasonable workaround for the model of this could be to use a Ruleset with a bypass list instead of a "classic branch protection rule". The Rulesets provide many of the same options for adding branch protections, such as "Require a pull request before merging" and "Require review from Code Owners". They also provide this bypass list feature that isn't available to the classic branch protection rules. By implementing the CODEOWNERS rule and granting CODEOWNERS the ability to bypass then only the CODEOWNERS can push without review, while everyone else needs a review by them.

Individual users cannot be specified in the Bypass list, though you can get the effective equivalent if you had only one user with the repo admin role.

Those in the bypass list will see the following checkbox:

[pascalguttmann]

@inickles Thanks for the info. That's a solution that works for our workflow. Even without the ability to bypassing the rules.
The number of Required approvals is set to 0.
The settings Require a pull request before merging, Require review from Code Owners and Dismiss stale pull request approvals when new commits are pushed are set.

This yields bahavior as expected when working alone with as a Codeowner in a pull request.

[pascalguttmann]

@inickles
After fiddling around and experimenting I realized another strange behavior of the CODEOWNERS feature of GitHub.
Consider

• a CODEOWNER CO of some files and
• some collaborator Eve

in the following workflow:

1. CO does some work on CODEOWNED files, that Eve is not allowed to change on the protected branch without review.
2. CO opens a PR to the protected branch and pushes the changes.
   a. The PR is now mergeable, because CO is the CODEOWNER of the changed files.
3. Eve changes files of which CO is the CODEOWNER and pushes them to the existing PR.

Observed behavior:
4. Eve can merge the PR with the unreviewed changes to files, that are NOT owned by Eve.
Because they are part of the PR, which was created by CO. Even though Eve pushed the changes.

Expected behavior:
4. Once Eve pushes changes to file not owned a review of the owner CO is required.

I could reproduce this with rulesets and "classic branch protection".
Is this as intended, do I miss a configuration to lock Eve out from merging?
Or am I missing the point of CODEOWNERS?
(My understanding: All changes to a owned file should be made or reviewed by a codeowner of that file.)

[YoshiRulz]

See also #6292.