pr create should have option to not require any commits/changes

[BryceLTaylor]

Describe the feature or problem you’d like to solve

We automate parts of our deploy workflow, including making release branches. In one type of release workflow we create a new release branch from main and then immediately make a PR back into main. Later we come back and do work on that release branch, and when it's done we merge in the PR. (this is slightly simplified, but those are the relevant parts of our workflow.

When I try to create a PR without immediately adding changes I get the error:

pull request create failed: GraphQL: No commits between main and hotfix/testing (createPullRequest)

Proposed solution

Provide a flag, such as --allow-empty that will let us create a PR with no changes.

Additional context

We are currently using repo-sync/pull-request@v2 which provides the option pr_allow_empty: true but no such option is available in the github cli. That repo now recommends using the gh cli.

[williammartin]

Thanks for the request. I'm a bit confused how pr_allow_empty: true actually works here. gh reproduces as you say:

➜ git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.

➜ git checkout -b wm/9112-triage
Switched to a new branch 'wm/9112-triage'

➜  gh pr create

Creating pull request for wm/9112-triage into main in williammartin-test-org/test-repo

? Title 9112-triage
? Body <Received>
? What's next? Submit

X operation failed. To restore: gh pr create --recover /var/folders/45/sdnm1hp10nj1s9q57dp3bc5h0000gn/T/gh3154501125.json

pull request create failed: GraphQL: No commits between main and wm/9112-triage (createPullRequest)

But then I looked at how repo-sync/pull-request@v2 works and it seems to use hub. This uses the pulls REST endpoint rather than GQL so I wondered if it had different behaviour but it doesn't seem so:

➜ GITHUB_TOKEN=$(gh auth token) hub pull-request
Error creating pull request: Unprocessable Entity (HTTP 422)
No commits between main and wm/9112-triage

And indeed using the REST API directly shows the same thing:

➜  gh api \
  --method POST \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  /repos/{owner}/{repo}/pulls \
   -f "title=9112-triage" -f "head=wm/9112-triage" -f "base=main" | cat

gh: Validation Failed (HTTP 422)
{"message":"Validation Failed","errors":[{"resource":"PullRequest","code":"custom","message":"No commits between main and wm/9112-triage"}],"documentation_url":"https://docs.github.com/rest/pulls/pulls#create-a-pull-request"}

I'll do a bit more investigation in the meantime but perhaps you know what obvious thing I'm missing?

[williammartin]

I guess what I'd like to know is what the state of the PR is when you use repo-sync/pull-request@v2 after it creates the PR but before you make any further changes. The repo-sync comments suggest that there would be a merge commit: https://github.com/repo-sync/pull-request/blob/b6e549fdc0a165604b1bc628a92184e5c6d1f531/entrypoint.sh#L114

And in fact if your branches are indeed exactly the same I would expect the script to exit before allow_pr_empty is even checked: https://github.com/repo-sync/pull-request/blob/b6e549fdc0a165604b1bc628a92184e5c6d1f531/entrypoint.sh#L109-L112

Perhaps you could take a screenshot of the commits of a newly created PR from repo-sync/pull-request@v2?

I get the sense something else is going on here because I can't see any way in which GitHub will allow you to create a truly empty PR.

[BryceLTaylor]

Hmm... I'm realizing that our existing workflows work on branches that do have changes and/or merge commits and it doesn't work the way I suspected when there aren't commits.

I still think this would be a good feature even if it isn't exactly how it worked in the other tool, since I would like to automate the creation of branches and creating prs back into the source branch.

[williammartin]

I still think this would be a good feature even if it isn't exactly how it worked in the other tool, since I would like to automate the creation of branches and creating prs back into the source branch.

I'm afraid it's not possible sorry, the GitHub platform itself isn't designed to work that way as you can see from the API responses. I can mention it to the team that owns pull requests but being realistic, it's very unlikely that such a core decision would be reviewed. If you really wanted to do this you'd probably have to do something like git commit --allow-empty to create an empty commit, then rebase it off the branch later.

[williammartin]

Closing this because it's not going to be addressed on the platform and there's no way we can get around it, sorry. Best of luck with your workflows.