Description
What Happened
In our GitHub Actions workflow, we have a naming collision in remote references (release/12.51.0 vs. release/12.51.0/with-simple-card-changes), which typically causes Git to throw an error:
error: cannot lock ref 'refs/remotes/origin/release/12.51.0/with-simple-card-changes':
'refs/remotes/origin/release/12.51.0' exists; cannot create
'refs/remotes/origin/release/12.51.0/with-simple-card-changes'
Despite this Git error, the actions/checkout@v4 step did not fail. The workflow continued as if the checkout had succeeded, but subsequent steps encountered failures or inconsistent refs.
Expected Behavior
If a Git fetch or checkout operation runs into a reference lock error (or any non-zero exit from Git), we expect the checkout step to fail immediately (return a non-zero exit code). That way, the pipeline knows the repository was not correctly checked out.
Actual Behavior
The checkout step logged an error but did not fail. It exited with a success status, leading to a misleading workflow state.
Environment
Using actions/checkout@v4 in GitHub Actions:
- uses: actions/checkout@v4
with:
fetch-depth: 0
token: ${{ secrets.FULL_ACCESS_TOKEN }}
The repository has (or had) conflicting branch references:
refs/remotes/origin/release/12.51.0 (a file)
refs/remotes/origin/release/12.51.0/with-simple-card-changes (would-be subfolder)
Note: we are not using continue-on-error on checkout step