jactor-rises
jactor-rises

Reputation: 3109

How to get the short sha for the github workflow?

I am creating a workflow in GitHub which creates and uses a docker image. Therefore I have started my workflow file with a global environment variable for this docker image which is visible for all the jobs in my workflow:

name: continuous integration
on:
  push:
    branches:
      - '**'

env:
  IMAGE: docker.pkg.github.com/${{ github.repository }}/jactor-persistence:${{ github.sha }}

I want to replace ${{ github.sha }} with the short sha of the head commit, the same as the result of the following command git rev-parse --short HEAD

Is this possible?

Upvotes: 95

Views: 120606

Answers (8)

ADV-IT
ADV-IT

Reputation: 851

In composite GitHub Action I'am using:

- name : Add SHORT_SHA Environment Variable
  id   : short-sha
  shell: bash      
  run  : echo "SHORT_SHA=`git rev-parse --short HEAD`" >> $GITHUB_ENV

And then use it like this:

- name : Build Docker Images
  shell: bash
  run  : |
    docker build -t "build" -f "MyDockerfile" .     
    docker tag "build" "$ECR_REPO:$IMAGE_TAG_PREFIX-$SHORT_SHA"
    docker push "$ECR_REPO:$IMAGE_TAG_PREFIX-$SHORT_SHA"

Upvotes: 0

Tim N
Tim N

Reputation: 150

I use a Github Action I wrote for this purpose:

https://github.com/eltimn/slugify-action

It also will replace some problematic characters in the branch name. It was modeled after Gitlab's code.

Upvotes: 1

matusf
matusf

Reputation: 601

You can use metadata-action to extract tags (and other metadata) from github events. From the metadata you can also get a short sha. Here is an example of jobs that extract short sha and subsequently use it to build a docker image:

- name: Extract metadata (tags, labels) for Docker
  id: meta
  uses: docker/metadata-action@v4
  with:
    images: ${{ env.REGISTRY }}/${{ github.repository }}
    tags: |
      type=sha,format=short,prefix=

- name: Build and push Docker image
  uses: docker/build-push-action@v4
  with:
    context: .
    push: true
    tags: ${{ steps.meta.outputs.tags }}
    labels: ${{ steps.meta.outputs.labels }}

You don't need to use it to build a new image. It can be accessed in following jobs via ${{ steps.meta.outputs.tags }}. Here meta is an id of job where the tags are defined.

Upvotes: 5

peterevans
peterevans

Reputation: 42210

As VonC mentioned, you can just compute the string yourself in a previous step.

      - name: Set outputs
        id: vars
        run: echo "sha_short=$(git rev-parse --short HEAD)" >> $GITHUB_OUTPUT
      - name: Check outputs
        run: echo ${{ steps.vars.outputs.sha_short }}

Upvotes: 125

PEK
PEK

Reputation: 4328

This works on Windows:

- name: Get short SHA
  run: echo "SHORT_SHA=$("${{ github.sha }}".SubString(0, 8))" >> $env:GITHUB_ENV

- name: Print short SHA
  run: echo "Short SHA is ${{ env.SHORT_SHA }}"

Upvotes: 7

ushuz
ushuz

Reputation: 814

Found a possible solution here, using bash's parameter substitution

- name: Step
  run: echo ${GITHUB_SHA::7}

Upvotes: 63

Lars Grammel
Lars Grammel

Reputation: 2168

You can also set an environment variable with the short sha:

    - name: Add SHORT_SHA env property with commit short sha
      run: echo "SHORT_SHA=`echo ${GITHUB_SHA} | cut -c1-8`" >> $GITHUB_ENV

SHORT_SHA can then be used like any other environment variable, e.g. like this:

    - name: My step
      run: myscript ${SHORT_SHA}

Upvotes: 55

VonC
VonC

Reputation: 1328112

It does not seem to be available: the github context only includes github.sha as the full commit sha (that triggered the workflow run)

You would need to somehow compute the string you want (by selecting only the first n characters of ${{ github.sha }}.

That means you can:

  • define a variable as shown in peterevans's answer
  • write it to the disk
  • cat $my_var to use your VAR in every step

See actions/starter-workflows issue 68 and examples.

But since Oct. 2019, you now have "Env at the workflow and job level"

It is common to need define a set of environment variables that are used in multiple steps in a job and even multiple jobs in a workflow.

Now you can add an env map at both the workflow and job level.
Those environment variables will be merged with the env defined at any step lower in the hierarchy.

See:

Upvotes: 4

Related Questions