GitHub Community
Assign yourself as a reviewer of your own pull request #6292
Replies: 34 comments 30 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I guess the easiest way right now would be to find an action that automatically approves a pull. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. Unfortunately this workaround requires a separate bot account to approve it. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Exactly, if I create a PR from dev -> prod but dev has changes from multiple people, I'd like to review them all together. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Same problem |
Beta Was this translation helpful? Give feedback.
-
|
Same here! |
Beta Was this translation helpful? Give feedback.
-
|
The same! |
Beta Was this translation helpful? Give feedback.
-
|
same in 2024 |
Beta Was this translation helpful? Give feedback.
-
|
Same here! |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Yea... What are you going to do if you are the sole developer on a repro? Not use the PR workflow? |
Beta Was this translation helpful? Give feedback.
-
|
Well, that's what I do. |
Beta Was this translation helpful? Give feedback.
-
|
If it's a public repo, you need PRs regardless. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
It remains extremely short-sighted that this is not possible. |
Beta Was this translation helpful? Give feedback.
-
|
For work we are using GitLab, so I only use GitHub for personal side projects. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I want to do the same myself. I am the owner and sole contributor. But I want to learn more about the GitHub process. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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.
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Yea, that's not gonna work, other than your auto-approve workflow. I found that GitHub prohibits one from approving their own pull request. |
Beta Was this translation helpful? Give feedback.
-
Don't know ! but count me in, I wanna review myself :) |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
One more thing besides all of the other comments: |
Beta Was this translation helpful? Give feedback.
-
|
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 🥳 |
Beta Was this translation helpful? Give feedback.
-
|
Bitbucket supports reviewing our own code( I think only for owners). This should also be there in GitHub. |
Beta Was this translation helpful? Give feedback.
-
|
The action of approval is to formally be responsible for the code merged, no matter it was produced by you or others. |
Beta Was this translation helpful? Give feedback.
-
|
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) |
Beta Was this translation helpful? Give feedback.
-
|
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) |
Beta Was this translation helpful? Give feedback.
-
|
That seems reasonable. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
As the organization owner and project admin, what if I want to be the sole reviewer on all PRs -- including my own? How can I do this? |
Beta Was this translation helpful? Give feedback.
-
|
So, as a project admin, that needs to approve all pull requests, I can not approve my own pull requests? That's insane... |
Beta Was this translation helpful? Give feedback.
-
|
I second this feature. Working with small teams, I can immediately see the benefits of being able to self approve PR. |
Beta Was this translation helpful? Give feedback.
-
|
+1 :) moving from gitlab to github this is a bit of a pita. |
Beta Was this translation helpful? Give feedback.
-
|
+1 would be nice for best practice. or assigning myself as the only one who can approve their own requests, with my teammates requiring a review. |
Beta Was this translation helpful? Give feedback.
-
|
It is not an answer but to prevent my self to click on merge to easily I now open my pull request as 'draft' so that I at least need to press "Ready for review" ... Cli : gh pr create --draft ... |
Beta Was this translation helpful? Give feedback.
-
|
It's 2024, no solution yet. Is anyone at GitHub listening? Or shall we all just switch to GitLab? |
Beta Was this translation helpful? Give feedback.
and others
-
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?
Beta Was this translation helpful? Give feedback.
All reactions