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.

[mwaddell]

Same problem

[ghkdqhrbals]

Same here!

[vvvictor07]

The same!

[surjikal]

same in 2024

[ariofrio]

Same here!

[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.

[mc0re]

If it's a public repo, you need PRs regardless.

[llegaz]

maybe gitlab is better for solo devs..

[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 :)

[llegaz]

microsoft teams' members are not able to introspection it seems

[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 🥳

[daewon-lee]

I second this feature. Working with small teams, I can immediately see the benefits of being able to self approve PR.

[CoolGoose]

+1 :) moving from gitlab to github this is a bit of a pita.

[hjc2]

+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.

[RemyNtshaykolo]

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 ...

[mc0re]

It's 2024, no solution yet. Is anyone at GitHub listening? Or shall we all just switch to GitLab?

[Daniel-Nldr]

We're a small team, and don't have the time or resources to have other members approve PR
We use automations to move our tasks along and the approval of a PR triggers all of that
Why on earth can this not be a settings, to allow authors to approve their own PRs

Github, anyone out there?? Listen to your community!!

[llegaz]

I'm not sure they care for small teams anymore.. they work for MICROSOFT :/

[mvanroon]

1. Developer 1 starts working on a feature and opens a PR
2. Developer 2 helps with the feature or takes over for whatever reason and needs developer 1 to review it
3. No way to request a review from developer 1 since (s)he opened the PR.

[oliveryasuna]

It is definitely surprising, the attention of this feature request, but no response to it. Unless GitHub has some super weird architecture, shouldn't they just have to remove the check...

[Daniel-Nldr]

We solved this by adding a GitHub action.
We have an account we use for all our automations
You need to create a classic access token, add the secret to the org or repo
All you then need to do is comment -APPROVED- and the automation and assigned account will do the rest
You could change the message to anything

Here is the Yaml File

name: Auto Approve PR
on:
issue_comment:
types: [created]
workflow_dispatch:
inputs:
pr_number:
description: 'Pull Request Number'
required: true
type: string

jobs:
auto-approve:
runs-on: ubuntu-latest
permissions:
pull-requests: write
contents: read
if: ${{ github.event.issue.pull_request && contains(github.event.comment.body, '-APPROVED-') }}
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
token: ${{ secrets.APPROVER_TOKEN }}

  - name: Approve Pull Request
    env:
      GH_TOKEN: ${{ secrets.APPROVER_TOKEN }}
      PR_NUMBER: ${{ github.event.issue.number || inputs.pr_number }}
      GITHUB_REPOSITORY: ${{ github.repository }}
    run: |
      gh pr review $PR_NUMBER --approve -R $GITHUB_REPOSITORY

[suthidesilva]

nice

[suthidesilva]

I might be completely wrong with what I am talking about here. If you're working on a GitHub project and need to approve your own pull requests, there’s a simple and effective way to automate the process using GitHub Actions. By setting up a workflow, you can trigger an approval when you add a specific comment (like -APPROVED-) to your pull request. This approach works perfectly for solo developers or small teams, where waiting for another reviewer isn't practical. The workflow uses a GitHub token to authenticate the action and programmatically approves the PR, keeping your process efficient and compliant with any automated pipelines or branch protection rules you’ve set up. It’s a seamless way to maintain a formal review process while ensuring you don’t get stuck in unnecessary bottlenecks.

[suthidesilva]

name: Auto Approve Pull Request
on:
issue_comment:
types: [created]

jobs:
auto-approve:
if: ${{ github.event.issue.pull_request && contains(github.event.comment.body, '-APPROVED-') }}
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4

  - name: Approve Pull Request
    env:
      GH_TOKEN: ${{ secrets.APPROVER_TOKEN }}
    run: |
      gh pr review ${{ github.event.issue.number }} --approve -R ${{ github.repository }}

[llegaz]

https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-teams-and-people-with-access-to-your-repository

[yuhr]

So many people revisit this request but the GitHub team doesn't care...

Is it that difficult to remove the code that removes the PR initiator from the list of reviewer candidates? I wonder what is actually blocking this from being implemented.

[BSchoolland]

I'm a bit late to the party, but I really want this as well!

I'd use it the way others have suggested, but another interesting use case is for AI, with cursor in YOLO mode I can assign an agent an issue and it will create a branch, attempt to solve the issue, test the changes and then make a PR. The problem is since my account is the one that creates the PR I'm unable to review the code generated by the AI. If I could, I would simply review it like I would any PR and then send it back to the agent with changes requested, but now I have to tell the AI what to change using a prompt.

I'm guessing something similar could apply to GitHub copilot too.

Please implement the ability to review your own PR! Would be such an easy and useful change!

[maslade]

GitHub PR's aren't feature complete until this is resolved. This restriction doesn't seem to benefit anyone.