Assign yourself as a reviewer of your own pull request

[douglaslassance]

It may sound weird, but there are cases where I wanted to review myself. Is there any reason why the creator of a given pull request cannot be assigned as a reviewer?

[Katsute]

If it's your own pull you probably don't need to assign a particular reviewer, considering you can just review it yourself without assignment.

[Katsute]

I guess the easiest way right now would be to find an action that automatically approves a pull.

[douglaslassance]

I'm not sure whether or not you are familiar with the new GitHub Issues which is currently in beta, but they have workflows that allow changing the status of a PR in the project based on approval. That said for this to work on my own PRs, I would have to approve them, and to approve them I would have to be a reviewer. This is a little bit of an issue that seats between General Feedback and Issues Feedback.

[Katsute]

I think approvals from any account will trigger workflows from the projects beta. I personally have done self approvals using a bot as the middle man.

KatsuteDev/JCore#6 (comment)

Unfortunately this workaround requires a separate bot account to approve it.

[douglaslassance]

That's an acceptable workaround, thanks for sharing. Personally, I don't think I miss the functionality so much that I would go out of my way to set this up. My post was mainly to flag that self-assignment should probably be possible to cover for cases like the ones I described.

[klaus19]

Yeah, self approvval is very much needed as my changes need to be reflected in main branch and I can't just wait for someone to approve the merge , its time consuming.

[aidan-mundy]

There are definitely other reasons that this should be supported. My immediate example is: If you create an MR using a branch developed by someone else, but still want to follow a standardized review process with proper assignments.

[kailukowiak]

Exactly, if I create a PR from dev -> prod but dev has changes from multiple people, I'd like to review them all together.

[stuart909]

I am lead in my repo and created a pull request for a commit from another junior dev. He was not able to do it so I wanted to do it for him so I could get the ball rolling. Now I cannot review the pull request because I technically initiated it. Seems all GitHub has to do is take out the condition that the requester cannot be in the reviewers group. Just my two cents.

[mcfarljw]

Adding my support for the scenario. It would be nice as a lead to be able to open a PR for someone else to be able to review with comments. We work in different timezones so if someone forgets to open a PR then I just end up providing feedback on Slack which is less than ideal.

[mwaddell]

Same problem

[ghkdqhrbals]

Same here!

[vvvictor07]

The same!

[surjikal]

same in 2024

[spenserblack]

Another use case for reviewing your own PR: I created a PR for a repo where I'm a collaborator. I then worked with the owner to implement some changes, but in the process I noticed a likely mistaken change that should be resolved before a merge. Specifically, a package-lock.json was added when we already had a yarn.lock. I wanted to mark the PR as "changes requested" so we could discuss which package manager was preferred before a merge, but couldn't because I was the author.
I think it makes sense to review your own PR once it becomes collaborative and has multiple committers, especially for changes that occurred after PR was created.

[douglaslassance]

Now that there is a YOLO badge for people who let un-reviewed PRs go through, I'm being publically shamed for creating reviews for myself that I cannot approve. 😄

[rioki]

Yea... What are you going to do if you are the sole developer on a repro? Not use the PR workflow?

[RalphHightower]

Well, that's what I do.

[pricehatfield]

The SLSA framework allows for trusted contributors to be 1 of 2 minimum reviewers on merges. It still protects against un-validated submissions, but does cut the red tape somewhat for senior team members and alleviate staffing requirements or people doing things not really part of their role. I'd love to see support in Github to assign this by team membership.

[SiJonesDLG]

It remains extremely short-sighted that this is not possible.
I have set up branch protection etc to prepare for incoming junior collaborators on a project where I am currently working solo.
So now I can't merge into the master branch myself? What a dumb limitation. It is just a poor design.

[jimgerth]

For work we are using GitLab, so I only use GitHub for personal side projects.
But for years, each time I start a new project on GitHub I come back to this same issue...
Its really annoying to not be able to go through the proper review process on your own (especially for new developers just getting used to the workflow).
Anyways, just wanted to let out some of my frustration with this.

[Hobart2967]

Alternative suggestion:

Create the PR as draft, then turn it into a real request. Possibly, you could fetch that type of event to check for a "final" PR to be merged and consider it as reviewed.

[rioki]

I actually ended up doing the following:

https://github.com/rioki/ice/blob/master/.github/workflows/auto-approve.yml

Not nice, but it works. I type LGTM as a comment and the actions bot approves the pull request. Same thing, just listening on a comment.

[RalphHightower]

I want to do the same myself. I am the owner and sole contributor. But I want to learn more about the GitHub process.

[RalphHightower]

After many attempts, it was by SDL (Sheer Dumb Luck) that I was able to approve and merge a pull request that I created for my solo owned repository.

[RalphHightower]

I have found the solution works for me; I am the only one working in the repository, so it may not be appropriate for other situations. On the settings page, select "Branches". Select "Edit" in the Branch Protection Rule.
Make sure that these two checkboxes are unchecked:

1. Require approvals
   When enabled, pull requests targeting a matching branch require a number of approvals and no changes requested before they can be merged.
2. Require approval from someone other than the last pusher
   Require review approval from someone other than the last pusher to the pull request branch.

[rioki]

That works, but merging is not approving. As project admin you can hit the red button at any time and override the approval steps. But this locks you out of auto merging when a build passes or some other automated checks. The whish is to be able to review your own code and actually punch the approve button and maybe even make workflow dependent on this.

Right now the possible solutions are all hacks, like my auto-approve.yml workflow how you can have the build bot approve on your behalf.

[RalphHightower]

Yea, that's not gonna work, other than your auto-approve workflow. I found that GitHub prohibits one from approving their own pull request.

[cx0y]

It may sound weird, but there are cases where I wanted to review myself. Is there any reason why the creator of a given pull request cannot be assigned as a reviewer?

Don't know ! but count me in, I wanna review myself :)

[reespozzi]

Seconded, another good use case is automated pull request workflows, the author (a bot in this case) should be able to approve it's own PR if it's something trivial and checks all pass.
It would be nice to keep the required reviews in place for PR's authored by humans, but allow complete auto-merge functionality for bots

[RalphHightower]

I don't think that auto-approving pull requests is a good idea. I think a human should be involved in approving pull requests. What happens if automation breaks the build process? Ralph

…

On Mon, Dec 12, 2022, 6:53 AM Rees Pozzi ***@***.***> wrote: Seconded, another good use case is automated pull request workflows, the author (a bot in this case) should be able to approve it's own PR if it's something trivial and checks all pass. It would be nice to keep the required reviews in place for PR's authored by humans, but allow complete auto-merge functionality for bots — Reply to this email directly, view it on GitHub <#6292 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHZ2PYWBE5ABAXX3IUYA3V3WM4G2JANCNFSM5F5L4RWQ> . You are receiving this because you commented.Message ID: ***@***.***>

[ucswift]

Throwing my 2c into this for a use case. I'm currently the only dev at a small biz and trying to setup the dev pipeline to be compliant with a number of industry certifications. Most of those, around the area of change management, require some approval process for changes into production (which I use a CI pipeline based off the master branch to do). I would be nice if self approval worked out of the box as that would allow a process to be in place that scales right out of the box and is consistent.

[jimgerth]

One more thing besides all of the other comments:
Maybe I'm missing something, but it seems like you need to be a reviewer of a pull request to be able to change its draft status.
This means, that I cannot create a draft pull request as a solo developer, which is simply ridiculous in my opinion.

[jimgerth]

Update: I still cannot assign myself as a reviewer of my own PR, but as of today I can convert my own PRs to drafts, which is all I really asked for anyway 🥳

[QuickBanjo]

Another use case is when you have two developers, with Required Reviews from Other Than Last Pusher. Dev 1 pushes and opens a PR, dev 2 is the reviewer. But suppose, after commenting on a minor issue, dev 2 fixes the issue and pushes, approving the remaining changes. You would expect that dev 1 could just review and approve the minor fix.

However, now neither developer can approve. Dev 1 can't approve because they opened the PR, but dev 2 can't approve, as they did the last push (this is correct, as the intent is to force dev 1 to review dev 2's changes). Prohibiting the PR opener from approving it also leads to issues in similar scenarios, such as when someone opens a PR when they weren't the last to push to the branch.

An option to allow PR openers to approve their own PR would allow better synergy with the (valuable) last-pusher option, in addition to the above use cases.

[dannykempkes]

In my case we're using the required review of code owner. If other people than the code owner make changes, we can be sure they are always reviewed by the code owner himself. But in case the code owner himself makes changes, the review is stuck because it's not allowed to approve your own pull request, but a code owner must approve.
So either we add a second code owner (which might not always be available at that time), or an admin needs to merge the request. These aren't valid options. There should be tick to make an exception that allows code owners to approve their own pull request.

[Lindsay-Mathieson]

Similar here, small Org, just two Devs, me the Admin/Code Owner and a newbie. I definitely want to enforce reviews on the new developer, but I can't because then he has to approve my Pull Requests, so I have to disable the rule to get work done.

Not allowing code owners to approve their own PR's is basically reducing security for small teams, not increasing it. It would be really good if we could nominate exclusions.

[mwaddell]

Same here - this rule makes no sense for very small teams.

I am the code owner on a repo, so I want to require that all PRs get approval from me in order to be merged. However, if I set a branch protection rule that PRs require code owner approval, then I am not allowed to create any of my own PRs, so I can't ever initiate any new work on the code that I am the owner of.

If I instead allow myself to override the branch protection rule, then I can't use auto-merge and I am not protecting myself from violating any of the other rules I'm trying to enforce (linear history, signed commits, CI/CD actions, etc) because I have to force-merge any of my PRs.

The simplest solution, in my mind, would be to allow Code Owners to review/approve any PR (including their own). However, I don't see GitHub doing that anytime soon, so we've been using the following workaround:

We have github actions automatically create Draft PRs for any new branch whose name matches a certain pattern. That way the "creator" of the PR is always "github-actions" and not any of us, so it doesn't matter who happened to "create" the new branch. If I, as code owner, am the one who pushed the commit which creates the branch, I can still review it, use auto-merge, enforce linear history, etc. I can even set the branch protection rules to prevent me from overriding these rules to protect my from myself.

It looks like the new "ruleset" approach would allow us to break up our branch protection rules into multiple rulesets where some could be bypassed but not others. This would solve part of our problem, but it is still not as clean as the workaround we are currently using because (a) there is no way to add CODEOWNERS to the bypass list, and (b) this just means certain users don't have to get approvals for their PRs, so our CI/CD actions which are triggered by a code review approval will never run.

[xiaoyuvax]

what's the conclusion? any follow-up?

[RalphHightower]

With the exception of your question, there's been no activity since February 22nd.
For solo repositories, my personal stuff, I have a work-around; but it's not suitable for 2+ developers.

[adwait009]

Bitbucket supports reviewing our own code( I think only for owners). This should also be there in GitHub.

[kftsehk]

The action of approval is to formally be responsible for the code merged, no matter it was produced by you or others.
So github is saying you cannot be the one responsible for the code you wrote, or the PR you opened. Nonsense.

[hrhszsdtcOfficial]

It is strongly recommended to add the setting for "Require approval from someone other than the last pusher".

I recently ran into a situation:I own my GitHub repository and I am the sole codeowner of the main branch. When I create a PR, the merge needs to be approved by the code owner, and I can't approve my own PR, so what do I do?I don't want to change the original settings of my repository(Require review from Code Owners)

[EyalRo]

In general, I would appreciate if we could see more "Warning, you shouldn't do this; continue? y/n" rather than "Error, we don't like this so you can't do it! cancel? y/y)

[varshneydevansh]

That seems reasonable.

[adrian-miasik]

Just ended up pulling someone's forked PR into our develop unintentionally. I had to force push the changes out but the PR has already been marked as merged. So, in order to have a proper review process, we needed to re-open the PR (which can't be done on merged PR's, so a new PR was created instead.) Since I had re-created a PR, I was no longer allowed to add myself as a reviewer. I was originally pulled in review for the forked PR.

I would very much like to see a change in this policy/leave it up to the repo maintainers so they can enforce this restriction at their own discretion.

[gioppoluca]

This settings is detrimental to projects where the main author does not have time to dedicate to the project and find a person in the open source ecosystem that want to be a collaborator, but if every time that there is a PR the owner has to come back to approve the review we are back into a deadlock situation, the project will starve since the owner do not have time, the collaborator will be frustrated since no one will review the PR and will leave the project or fork it for good. Really pretending to "overly support control" is not helping here.
Add an option to allow collaborators to approve their own PR if the project is happy with that why github have to enforce a behavior?

[oliveryasuna]

This would be useful. I was handling a case that was almost complete, so I opened a draft PR. We then decided that it needed further work before merging. I handed off that work to another developer. I cannot leave a formal review on the PR since I opened it.

[pspot2]

This is absolutely fantastic (in a negative sense). Considering the additional shortcomings like a cryptic way of setting up pull request templates as well as lack of a decent embedded web IDE, I guess I'll stay with GitLab for the moment.

[SIDANWhatever]

Same issue still annoying me in 2024. I wanted to just simply preventing anyone (admin incl.) to directly push to main. Admin requires no reviews for a PR but anyone else requires at least 1 admin to review. But I cannot configure it directly branch protection rule LOL