GITHUB_SHA not the same as the triggering commit

[ibiqlik]

Hi all,

I am seeing a very strange behaviour in Workflows, specifically the commit id as provided by GITHUB_SHA environment variable.

The GITHUB_SHA variable is not the same as the SHA commit that triggers the workflow (on pull_request). 

What’s more strange is that the commit from GITHUB_SHA env variable is not in git at all, I just get fatal: bad object

Can someone please shed some light for me?

image.png1083×579 38.7 KB

[Yanjingzhu]

Hi @ibiqlik , 

This is an expected behavior for pull_request event. 

When you push to the source branch of a pull request , a workflow with on pull_request will be triggered. The triggered commit is on the source branch . 

But this is not the GITHUB_SHA for pull_request event. The GITHUB_REF for pull_request event is PR  merge branch refs/pull/:prNumber/merge. And the GITHUB_SHA  is the last merge commit on the GITHUB_REF branch. This GITHUB_SHA does not exist in any current branch in repo. So you will get fatal: bad object. 

PR event.png739×489 16.5 KB

[ibiqlik]

Ah missed that detail, thanks for pointing it out for me.

Can get the commit I want using:

if [ "$GITHUB_EVENT_NAME" == "pull_request" ]; then
    GITHUB_SHA=$(cat $GITHUB_EVENT_PATH | jq -r .pull_request.head.sha)
fi

Or (not tested) https://github.com/actions/checkout#checkout-pull-request-head-commit-instead-of-merge-commit

[YakirGiladiEleos]

Thanks ! it is really helped !

[wbrefvem]

@yanjingzhu

This strikes me as a very bizarre and counter-intuitive behavior. So I create a PR, push another commit, my branch then gets merged into another branch, and that branch triggers the workflow? So there’s a merge commit I’ve never seen, and I can’t access the branch I care about unless I explicitly check it out? How does this make any sense?

The docs for environment variables say that GITHUB_SHA refers to the commit that triggered the workflow. (Environment variables - GitHub Docs) The commit I pushed is the commit that triggered the workflow, not the merge commit. I don’t care that under the covers there’s a whole other branch that my branch gets merged into, and then that branch triggers the workflow. It has literally zero relevance to what I’m doing. I want to build the commit that I pushed, and I want to be able to tag artifacts with its SHA. It took me an hour to realize that I have to explicitly check out my branch, because the workflow’s workspace is on a completely different branch by default. This is bad UX. Bad! LIke, pre-CoreOS Red Hat bad. Not what I expect from GitHub.

[sdhull]

100000%!!!

Can I upvote this comment a few more (thousand) times? This behavior is seriously unhinged. Principle Of Most Surprise

[ibiqlik]

😆 what doesn’t make sense? That I want the SHA of my commit instead of merge commit on PULL_REQUEST event or the shell code?

[AllanOricil]

Sorry, your code helped me actually haha
My comment was for this weird behaviour

[corentingiraud]

I can confirm that ${{ github.event.pull_request.head.sha }} works as well!

[ibrahima]

Hm wouldn't this technically be the last commit on the PR rather than the one that triggered the build? So like, if you try to use this to rebuild a commit that's not the latest it will just return the latest source anyway? That seems slightly annoying, though really this whole issue is very strange.

[johnboiles]

I have this question too. Is ${{ github.event.pull_request.head.sha }} going to have problems if you rerun a CI run on a prior commit?

[AllanOricil]

The event payload won't change if you rerun the workflow.

[johnboiles]

Great news

[kamilmodest]

I want to have one workflow for both: push and pull_request events. So how can I get the proper SHA of the last commit that works for both these cases?

I mean case when my workflow starts with:

on:
  pull_request:
  push:
    branches:
      - main
      - develop

If I use github.event.pull_request.head.sha, it won't work when it's a push to branch.
If I use GITHUB_SHA, it won't work when it's a pull request.

[JamesMGreene]

You can have an expression that uses them like a [navigation-safe] fallback, e.g.

    steps:
      - run: echo "Relevant commit SHA: $RELEVANT_SHA"
        env:
          RELEVANT_SHA: ${{ github.event.pull_request.head.sha || github.sha }}

[psionic-k]

Something should have been abstracted out. This feels like implementation detail leaking into variables that had extremely intuitive semantics.

User's would only ever need the merge sha iron out edge cases that they should know about from the context of what they are doing. What needs to happen is that more specific information should be placed into longer variable names and the less specific information such as GITHUB_SHA need to always point to the original triggering commit, not the sha introduced by the implementation.

I ran into this after force pushing a branch. CI works 99 times out of 10 and then suddenly this GITHUB_SHA value that doesn't correspond to my branch head shows up. The SHA appears to be created during the workflow. It will never exist in my history, so why even set it to an environment variable? The behavior was inconsistent across other force pushes and pull requests, so I still don't understand the specific mechanism that results in this situation.

In what universe will errors not result from supplying the user with a variable that appears valid yet cannot be used? If it's expected, it's still wrong.

[sdhull]

I was wondering why I found an action specified like this in my repo:

    steps:
      - name: Determine git sha to checkout
        uses: haya14busa/action-cond@v1
        id: gitsha
        with:
          cond: ${{ github.event_name == 'pull_request' }}
          if_true: ${{ github.event.pull_request.head.sha }}
          if_false: ${{ github.sha }}
      - name: Checkout ref
        uses: actions/checkout@v3
        with:
          ref: ${{ steps.gitsha.outputs.value }}

When I read this my first thought was "this is silly, this must be reproducing default Github Action behavior" but lo and behold... 😖 this is actually necessary to make the action check out the correct sha for the branch!