create-pull-request icon indicating copy to clipboard operation
create-pull-request copied to clipboard

Random error in the prune remote step

Open VDVsx opened this issue 2 months ago • 8 comments

Description

We have several workflows running on a 6-hour schedule that have been working without issues for months using peter-evans/create-pull-request@271a8d0340265f705b14b6d32b9829c1cb33d45e # v7.0.8 action. Recently, we started to observe random failures across all of them, usually not more than one failure per day(1 out of 4 fails). These seem to be completely random. In all the cases I checked, there was no pull request open with the same branch name, nor would the action create a pull request(no change).

The error always occurs in the Checking the base repository state step. We have seen two different cases:

Most common:

Checking the base repository state
  /usr/bin/git symbolic-ref HEAD --short
  master
  Working base is branch 'master'
  /usr/bin/git remote prune origin
  remote: Repository not found.
  fatal: repository 'https://github.com/REDACTED' not found
  Error: The process '/usr/bin/git' failed with exit code 128

Less common:

Checking the base repository state
  /usr/bin/git symbolic-ref HEAD --short
  master
  Working base is branch 'master'
  /usr/bin/git remote prune origin
  error: RPC failed; HTTP 404 curl 22 The requested URL returned error: 404
  fatal: expected flush after ref listing
  Error: The process '/usr/bin/git' failed with exit code 128

Extra details

All our workflows run on self-hosted runners, as described above it may or may not create pull requests, depending on changes in another system.

Our action configuration:

- name: Create Pull Request
        id: create-pull-request
        uses: peter-evans/create-pull-request@271a8d0340265f705b14b6d32b9829c1cb33d45e # v7.0.8
        with:
          title: REDACTED
          body: REDACTED
          commit-message: REDACTED
          base: ${{ github.event.repository.default_branch }}
          branch: REDACTED
          token: ${{ steps.app-token.outputs.token }}
          sign-commits: true

If you need more details or logs, happy to provide.

P.S.: Thanks a lot for your amazing work in all the GH actions you provide to the community.

VDVsx avatar Oct 27 '25 08:10 VDVsx

+1

smallprogram avatar Nov 14 '25 02:11 smallprogram

+1

francescodone avatar Dec 02 '25 06:12 francescodone

I'm also running into this issue. This feels like a GitHub issue, and I'm probably going to work around it by adding a retry (😢🐼). I haven't seen a regular (if intermittent) problem like this in other workflows or actions.

I've compared the logs of successful and failing runs and I don't see anything untoward. Like @VDVsx, however, I'm also using an app token…

blalor avatar Dec 02 '25 13:12 blalor

Thank you for reporting @VDVsx

Is there anyone experiencing this that isn't on self-hosted?

That particular git command was added due to an issue on self-hosted runners: https://github.com/peter-evans/create-pull-request/blob/bc8a47f5657f110049f4afd030c95529a9c62b76/src/create-pull-request.ts#L124-L129

peter-evans avatar Dec 02 '25 20:12 peter-evans

I'm using a GH-hosted runner, just ubuntu-latest for the job that fails most often.

blalor avatar Dec 02 '25 21:12 blalor

I've released an update in v7.0.11 / v7, that restricts the git remote prune step to self-hosted runners only. When I originally introduced that step I didn't know how to restrict it to self-hosted, but I've now found a solution.

This should limit the issue to those running on self-hosted.

peter-evans avatar Dec 05 '25 17:12 peter-evans

I've released an update in v7.0.11 / v7, that restricts the git remote prune step to self-hosted runners only. When I originally introduced that step I didn't know how to restrict it to self-hosted, but I've now found a solution.

This should limit the issue to those running on self-hosted.

FWIW, while I have not seen this particular error myself, we use ephemeral self-hosted runners (as do many others I imagine, as stacks like ARC, terraform-aws-github-runner and runs-on.com support them), so this code comment isn't always true I presume?

// For self-hosted runners the repository state persists between runs.

jpalomaki avatar Dec 08 '25 08:12 jpalomaki

use github gh cli fixed this error

smallprogram avatar Dec 08 '25 10:12 smallprogram