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

[frode-carlsen]

when upgrading to @v2 or later it no longer accepts a single short sha for the ref parameter, and the git command fails:

Setup

uses: actions/[email protected]
   with:
     ref: 7daa143

Output:

/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=5 origin +refs/heads/7daa143*:refs/remotes/origin/7daa143* +refs/tags/7daa143*:refs/tags/7daa143*
  The process '/usr/bin/git' failed with exit code 1
  Waiting 18 seconds before trying again

[ericsciple]

For improved perf, v2 only fetches a single commit by default. If you set fetch-depth: 0 then will fetch all history for all branches and tags and the short sha will probably work. Otherwise need to specify the full SHA.

[frode-carlsen]

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

[ericsciple]

Thanks for confirmation.

Fyi - I updated the title to clarify "short sha" instead of "single ref"

[ericsciple]

Also I marked as enhancement.

Adding some thoughts regarding implementation: I wonder if the git fetch allows a short sha, or whether would need to query REST API to resolve.

Also would need to be implemented for the case when git 2.18 not in the PATH, and fallback to download the tarball from the REST API.

[jsumners]

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.

[stleamist]

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.

@jsumners fromJSON will unquote the string.

ref: ${{ fromJSON(steps.pr-branch.outputs.result) }}

[bpleines]

Unsurprisingly this also affects checkout@v3. Reverting back to v1 satisfied my use case as many others have suggested

[yasarutkuu]

same problem, checkout@v2 doesnt support short sha

[weineran]

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.

However, it would be really nice if we could pass in the short SHA directly like we could in v1.

[prein]

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?

[socketbox]

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.

[jlongo-encora]

Any updates here? This would be a good feature to return.

[gentoorax]

Bump +1 - please return this feature, I've had to move back to v1. Totally agree with @socketbox.

[thockin]

I stumbled on this because I also have a tool that would like to use short SHA's, but like this one it uses git fetch which does not resolve short SHA's. If there is a way to ask a remote "please expand this short SHA", I don't know what it is. That means that both checkout and my own tool both require full SHAs.

If there is a way to do this, please tell me (us).

[ryan-williams]

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)