checkout: Upgrading @v1.2 -> @v2 can no longer specify short sha in ref

For now, as a workaround, I am using

fullSHA=$(git rev-parse ${shortSHA})

in order to get the full SHA from the short SHA, then passing the full SHA to the checkout action.

Isn’t is a chicken and egg problem? How can you run git rev-parse before checkout?

What I’m failing to grasp here is the notion that this is somehow an enhancement, when it seems like a regression: this was a part of functionality that was working and is now not working. Unless there was a deliberate design decision to remove short hashes from acceptable inputs (and I certainly haven’t done enough digging to ascertain as much), I don’t think this issue can accurately be characterized as a feature request.

I just ran into this, and worked around it by using gh to resolve a short SHA to a full SHA (without checking out the repository), then passing the full SHA to actions/checkout:

on:
  workflow_dispatch:
    inputs:
      ref:
        type: string
        default: main
        description: "The branch, tag, or SHA to run the workflow from"
jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - name: Resolve inputs.ref to full SHA
        id: resolve-ref
        # https://github.com/actions/checkout/issues/265
        env:
          GH_TOKEN: ${{ secrets.GH_TOKEN }}
        run: |
          ref=${{ inputs.ref }}
          sha=$(gh api /repos/$GITHUB_REPOSITORY/commits/$ref | jq -r .sha)
          if [ -z "$sha" ]; then
            echo "Failed to resolve ref $ref (possibly missing GH_TOKEN env var?)" >&2
            exit 1
          fi
          echo "Expanded ref $ref to SHA $sha"
          echo "sha=$sha" >> $GITHUB_OUTPUT
      - uses: actions/checkout@v4
        with:
          ref: ${{ steps.resolve-ref.outputs.sha }}

(source)

Note that:

• Calling gh requires a GH_TOKEN secret (docs).
• The above will resolve all refs (including branch names) to a SHA. If something later in the job requires a specific branch to be checked out, that might break.

In my case, another workflow was calling this one, and passing the short SHA; I also needed secrets: inherit at the call-site:

rebuild_www:
  name: Rebuild www
  needs: refresh_data
  if: needs.refresh_data.outputs.build_www
  uses: ./.github/workflows/www.yml
  secrets: inherit
  with:
    ref: ${{ needs.refresh_data.outputs.sha }}

(source)

Adding some more info here.

I have a set of steps like:

- name: Lookup Branch
        uses: actions/github-script@v3
        id: pr-branch
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const response = await github.pulls.get({
              owner: context.repo.owner,
              repo: context.repo.repo,
              pull_number: context.issue.number
            })
            return response.data.head.ref

- name: Checkout
        uses: actions/checkout@v2
        with:
          ref: ${{ steps.pr-branch.outputs.result }}
          persist-credentials: false

That resu

This ends up trying to issue the command:

/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +refs/heads/"test-6"*:refs/remotes/origin/"test-6"* +refs/tags/"test-6"*:refs/tags/"test-6"*

Notice that the short ref is being quoted in the command. I don’t know if that matters or not, but it’s definitely failing. Switching back to @v1 works.

tnx, fetch-depth: 0 doesn’t make any difference, just got a different error. but full sha works. Seems the checkout command it generates assumes it’s a branch or tag when it’s a short hash (7 chars) and thereafter generates an invalid checkout command

With a full sha it generrates this checkout command - same as it should be if a short sha had been treated the same /usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +7daa1431d70a06da41e2da7f2ade272bee3d56ca:refs/remotes/pull/515/merge