provide git commit hash in outputs

[toffaletti]

It would be helpful for creating cache keys if we could get the exact commit hash of a ref that might float like 'master'.

[ericsciple]

I'm not opposed to adding, but curious more info about the scenario? Including the SHA in the cache key seems wrong since it will change every run.

I'm thinking of scenarios like npm. Restoring from cache will cover most packages, even when some packages change between runs. The branch seems like a better approach (e.g master vs legacy).

Workaround today is the set-output command. Something like echo "::set-output name=sha::$(git rev-parse HEAD)"

[toffaletti]

Sure, here’s the scenario:

We need to build the protobuf repo as part of CI for a protoc plugin. To run the conformance test. We want to follow master on the protobuf repo because they add new tests all the time. The CI workflow is happening inside a docker image provided by the Swift project which has an old version of git so the checkout action is using the http api instead of git, so we can’t run git rev-parse (I tried this first). If I use the branch name in the cache key then we potentially miss updates to the protobuf conformance test until the cache expires.

[ericsciple]

@toffaletti thanks that helps!

Here is a workaround to determine the SHA, and then pass the same SHA into the checkout step:

    steps:
      - id: get-sha
        run: |
          echo ::set-output name=sha::$( curl -u "u:${{github.token}}" https://api.github.com/repos/some-owner/some-repo/git/ref/heads/master | jq .object.sha | tr -d '"' )
      - uses: actions/checkout@v2
        with:
          ref: ${{ steps.get-sha.outputs.sha }}

[bcardiff]

I second the idea of this feature.

In my use case we checkout many repos to build them and do some integration testing. Having the sha in the output will simplify caching some intermediate build steps.

[brachipa]

In my use case i checkout another branch and I want the commit sha for surefire-report

[TheFirstAvenger]

I would like to use the SHA to tag docker images. If I am reading this correctly, I could do that with this feature.

[Kampe]

This would also be valuable to us on being able to grab the SHA of the container build on merge (HEAD^1)

[soloturn]

can one run a shell script and output the last tag + the number of commits since the last tag, to have a notion of "newer" + the sha to have a clear reference to the source code without tag, sample output would be 1.7.94-57-g2167aa34 or 1.7.94.r57.g2167aa34:

´´´
git describe --long --tags | sed 's/([^-]-g)/\1/'
git describe --long --tags | sed 's/([^-]-g)/r\1/;s/-/./g'
´´

[tdemin]

Particularly useful for cases where an arbitrary tag is being checked out (manual workflow dispatch, for instance), and then the revision is getting used elsewhere: opencontainers spec suggests putting org.opencontainers.revision label to denote the specific VCS commit an image has been built from. Something like:

jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        id: vcs
        with:
          ref: ${{ github.event.inputs.tag }}
      ...
      - name: Build & push
        uses: docker/build-push-action@v2
        with:
          ...
          labels: |
            org.opencontainers.image.revision=${{ steps.vcs.outputs.commit }}

[schwabe]

I want to second this, scenario here is similar to @toffaletti is saying. Checkout some release/master branch of dependency but only rebuild the dependency if that commit has changed. Or is there an action that allows querying a commit id for a git repository?

[Kerilk]

For all the reasons listed above, it would be a great feature to add.

[john01kpeazu]

Keeping this thread alive. My team also uses commit SHAs to tag Docker images in ECR.

[ericcornelissen]

This seems to have been resolved with #1180 (see also #281)