Non-standard ref names are no longer found
Background
In our repository workflow, we are creating a merge commit of some PRs and pushing it using the naming scheme refs/deploy-bot/${runId}/merge. This is then checked out in later dependant steps, by passing this value as ref:.
Problem description
This stopped working in 4.1.7 with the changes from #1774.
Checkout now results in an error:
Error: A branch or tag with the name 'refs/deploy-bot/9543036827/merge' could not be found
Attempted solutions
I tried switching to an "unqualified ref" name deploy-bot/9543036827/merge in the hopes that the branch can then be found, but then the checkout already fails during fetching:
Fetching the repository
/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --no-recurse-submodules --depth=1 origin +refs/heads/deploy-bot/9545625056/merge*:refs/remotes/origin/deploy-bot/9545625056/merge* +refs/tags/deploy-bot/9545625056/merge*:refs/tags/deploy-bot/9545625056/merge*
The process '/usr/bin/git' failed with exit code 1
Waiting 17 seconds before trying again
...
Alternative solutions
- Use a standard branch ref or tag ref. We would like to avoid having to use standard branch or tag refs, because we don't want to clutter the branch listings in git output and the GitHub UI with our temporary branch names.
I am also seeing this and we are also using non standard tags. I just tried a workaround that I thought would work but it didn't and failed during the actions/checkout call:
- name: Checkout
uses: 'actions/checkout@v4'
with:
fetch-depth: 0
ref: develop
- name: Switch to tag
run: |
git fetch --all --tags
git checkout -b customTag [tag]
This is the error I am getting:
/opt/homebrew/bin/git -c protocol.version=2 fetch --prune --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/*
remote: Repository not found.
Error: fatal: repository 'https://github.com/xxxx/xxxx/' not found
The process '/opt/homebrew/bin/git' failed with exit code 128
Waiting 11 seconds before trying again
/opt/homebrew/bin/git -c protocol.version=2 fetch --prune --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/*
remote: Repository not found.
Error: fatal: repository 'https://github.com/xxxx/xxxx/' not found
Error: The process '/opt/homebrew/bin/git' failed with exit code 128
Can you provide an example workflow of how you were successfully checking out non-standard refs?
Sure, here is a minimal example that demonstrates the breakage introduced with 4.1.7 (breakage in a sense regardless of whether or not this ever was officially supported) https://github.com/oxc/actions-checkout-issue-1782/actions/workflows/demo.yaml
https://github.com/oxc/actions-checkout-issue-1782/blob/main/.github/workflows/demo.yaml
name: Demo for non-standard ref names issue
on:
workflow_dispatch:
jobs:
push_ref:
name: Create non-standard ref name
runs-on: ubuntu-latest
outputs:
ref: ${{ steps.push.outputs.ref }}
permissions:
contents: write
steps:
- name: Checkout repo
uses: actions/checkout@v4
- name: Create dummy commit, and push as non-standard ref
id: push
run: |
git config user.name 'github-actions[bot]'
git config user.email '41898282+github-actions[bot]@users.noreply.github.com'
echo "Dummy" > dummy
git add dummy
git commit -m 'Dummy commit (run id ${{ github.run_id }})'
git push origin HEAD:$REF
echo "ref=$REF" >> "$GITHUB_OUTPUT"
env:
REF: "refs/deploy-bot/${{ github.run_id }}/merge"
checkout_old_working:
name: Checkout non-standard ref name (working @4.1.6)
runs-on: ubuntu-latest
needs: push_ref
steps:
- name: Checkout repo
uses: actions/[email protected]
with:
ref: ${{ needs.push_ref.outputs.ref }}
- name: Show latest commit
run: |
git log -1
cat dummy
checkout_new_failing:
name: Checkout non-standard ref name (failing @ > 4.1.6)
runs-on: ubuntu-latest
needs: push_ref
steps:
- name: Checkout repo
uses: actions/checkout@v4
with:
ref: ${{ needs.push_ref.outputs.ref }}
- name: Show latest commit
run: |
git log -1
cat dummy
@oxc Really helpful example, thank you ✨ I opened https://github.com/actions/checkout/pull/1924 to bring back support for that kind of use case.