Assign yourself as a reviewer of your own pull request #6292
Replies: 28 comments 29 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.
-
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.
-
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.
-
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.
-
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.
-
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 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.
-
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.
-
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.
-
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. |
Beta Was this translation helpful? Give feedback.
-
In my case we're using the |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
what's the conclusion? any follow-up? |
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.
-
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.
-
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