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.

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

[lrperlmu]

How about the kind of code review where I invite a colleague to my desk and we review it together, but I'm the one who's logged in at my computer so the collaborative code review looks like it's done by me.

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

[surjikal]

same in 2024

[ariofrio]

Same here!

[johnny-shepherd]

same

[sdg002]

Azure Devops repository has this feature and has worked very well in my organization. I would like Github to have this feature too.

[ariukkonen]

Same in 2025. Some of us have our own projects and we want to follow the correct workflow in those as well instead of always bypassing the rules or using the commandline.

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

[vivasvan-patel-ev]

link is dead!

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

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

[Waterstraal]

^ This exactly.

The description under this check is misleading, because the PR author is not the one who pushed the last commit:

GitHub could do 2 things:

• Change the default behavior to be more intuitive and allow PR author's to approve the PR when the last commit is not their own
• Add another check: PR authors can approve their own PRs

Also, the current behavior is not well documented. Improving the docs in the rulesets should be done regardless.

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

[sdepouw]

+1 from me.

You can absolutely make it a configuration setting per-repository or per-organization (with the default behavior being the current behavior), but let us self-review if we want to!

[NoamGaash]

another use case -
my boss created a failing test (TDD approach) that demonstrate an issue. I'm working on the PR he initialized to fix the issue until all tests are passing again. Now I want to ask him to review my work, but can't since he was the one created the pr.

[vivimage]

Another use case -
You created a pull request through open ai codex agent. And now you want to review and approve it but you cant

[MarkS-AL]

Can't believe this issue remains unresolved.
This action will approve as [github-actions], supply the PR number as the job run arg:

on:
  workflow_dispatch:
    inputs:
      pr_number:
        description: 'PR number to approve'
        required: true
        type: string

jobs:
  approve:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        
      - name: Approve PR
        run: |
          gh pr review ${{ inputs.pr_number }} --approve
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

You need to manually merge after approval.

[abjugard]

Super annoying, what the hell Github...