Random error in the prune remote step
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.
+1
+1
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…
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
I'm using a GH-hosted runner, just ubuntu-latest for the job that fails most often.
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.
I've released an update in
v7.0.11/v7, that restricts thegit remote prunestep 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.
use github gh cli fixed this error