Repository navigation
Provide gh cli Support to Revert Pull Request #6034
Description
Activity
Thanks for the feature request! Agreed that this would be useful, but I do not think there is an API to revert a merged PR. Until then, we cannot act on adding this to CLI.
In the meantime, you can use
gh pr viewto determine the merge commit for a PR and use git locally to revert that merge commit:gh pr view PRNUM --json mergeCommit -q .mergeCommit.oidThere's a
revertResourcePathattribute in the pullrequest Object in the GraphQL API. Unsure if that's useful for request, but worth looking at.@azizshamim @mislav Any chance there has been any progress here?
There's a revertResourcePath attribute in the pullrequest Object in the GraphQL API. Unsure if that's useful for request, but worth looking at.
This URL is for use in the browser; the best the CLI could do is link to it.
Reacted by Mislav MarohnićOne team is migrating from Gerrit and want to mimic some of the capabilities that Gerrit has. Gerrit has
topicswhich are essentially multi-repo PRs. GitHub PRs are scoped to a single repo.What they are planning to do is link a set of PRs (to simulate the
topicconstruct). I think this request comes from their commit process - if they approve atopic, they will merge the set of PRs - but if something fails, they want to be able to revert the merge.Update: the platform team just shipped a new API to revert a PR with:
mutation ($pr: ID!, $asDraft: Boolean = false, $title: String, $body: String) { revertPullRequest( input: { title: $title, body: $body, draft: $asDraft, pullRequestId: $pr, } ) { revertPullRequest { url } } }
You can already use this as so:
# reads the query from a file: gh api graphql -F [email protected] -f 'pr=<PR-ID>'
How should we expose this as a command in gh?
gh pr revert <PR>gh pr merge --undo <PR>(sort of likegh pr ready --undo)
Reacted by Rocktim and AzeemI feel like
gh pr revert <PR>makes more sense intuitively, as in the web UI 'revert' is shown separately akin to how 'close' is shown separately.When you revert a PR, you're not inherently "undoing" the merge, you're rather making a new change that reverts the commit itself.
gh pr merge --undomight imply to some people that it will undo the state of the pull request / reopen it and so on. It could also be understood to mean restoring the branch to it's former state, as if you had force pushed an older commit back to entirely get rid of the commit history / the fact it was ever merged.Reacted by Arun2 remaining items
Work prioritization looks like this: if something is tagged
help wanted, that means that there should be enough information in the thread for an outside contributor to pick up the feature and produce a pull request. https://github.com/cli/cli/blob/trunk/.github/CONTRIBUTING.mdEventually, our team might also pick up this work, but before we manage to get to it, anyone is welcome to!
What's needed to help the PR progress to being reviewed and (hopefully) merged?
I'm pretty interested in using this functionality after trying out the GraphQL approach with some success.
Wanted to check in on the above as well. Happy to jump in if needed to help merge the open PR!
@connor15mcc there's nothing currently blocking it AFAIK - it's in our review backlog. Sorry!
Ack. LMK if I can provide an extra set of hands!
AI thinks you can already do that. Looks like reality needs to catch up! :)
Reacted by Connor McCarthy, Kynan Ware, Rocktim and Gordon McNaughtonStatus update
A brief status update from our Help Wanted sync, cc @babakks
We need to define Acceptance Criteria ✏️
revertpullrequestinputtakesbody,draft, andtitle. So we should probably support--body,--draft, and--titleflags.- There's no clean or apparent API driven way to do
--web, so we don't want that scoped in on this work. - We don't want to prompt for
--body,--draft, or--title. - The URL of the new revert PR should be returned or an error if there was an error.
- We do not want any local branch PR detection to decide which PR to revert, which would make the argument optional. We don't want this because the value proposition for such a feature isn't very apparent and there are light risks to reverting a PR that you didn't intend to 🤷
After that, we should mention the interested parties and see if anyone is interested in continuing the work on the #8826
Acceptance Criteria
-
Missing argument
Given I rungh pr revertwith no<PR>
Then it exits non-zero and prints an argument error. -
Accepted PR identifier formats
Given a merged PR exists
When I rungh pr revert 123,gh pr revert owner/repo#123, orgh pr revert https://github.com/owner/repo/pull/123
Then a revert PR is created and only its URL is printed. -
Merged PR requirement
Given the target PR is not merged
When I rungh pr revert <PR>
Then it fails (API error), no URL printed, non-zero exit. -
Basic revert (no flags)
Given a merged PR
When I rungh pr revert <PR>
Then a revert PR is created with backend-generated title/body; only URL printed. -
With title/body
Given I pass--title "T"and/or--body "B"
When I run the command
Then those values are sent; revert PR created; only URL printed. -
With draft
Given I pass--draft
When I run the command
Then the revert PR is a draft; only URL printed. -
API failure (permissions / already reverted / conflict / other)
Given the API rejects the mutation
When I run the command
Then stderr shows the API error; stdout empty; non-zero exit. -
Multiple invocations
Given I run the command multiple times on the same merged PR
Then behavior depends solely on API response (no local duplicate guard). -
No implicit PR inference
Given I am on a branch related to the original PR
When I omit<PR>
Then the command fails as in Scenario 1 (no auto-detection).
-
Describe the feature or problem you’d like to solve
To support automation and CI/CD it would be beneficial for the GitHub CLI to support reverting a pull request equivalent to what the UI is able to accomplish.
Proposed solution
gh pr revert 416967111Additional context
In a multi-contributor, pull-request managed repository there are limits to what linting/formating/plan (e.g. terraform plan) can achieve before attempting to deploy (e.g. terraform apply). To increase velocity, and minimize effort required by maintainers, it would be beneficial to be able to revert a PR following a failed build/deploy.