GITHUB_SHA not the same as the triggering commit

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?


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

1 Like

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)

Or (not tested)



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.


:laughing: 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?

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

1 Like