GITHUB_SHA not the same as the triggering commit #26325

ibiqlik · 2020-04-30T13:40:52Z

ibiqlik
Apr 30, 2020

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.png 1083×579 38.7 KB

Answered by Yanjingzhu

May 1, 2020

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.png 739×489 16.5 KB

View full answer

Yanjingzhu · 2020-05-01T02:36:27Z

Yanjingzhu
May 1, 2020

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.png 739×489 16.5 KB

0 replies

ibiqlik · 2020-05-04T09:13:43Z

ibiqlik
May 4, 2020
Author

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

1 reply

YakirGiladiEleos Nov 23, 2023

Thanks ! it is really helped !

wbrefvem · 2021-03-02T04:08:17Z

wbrefvem
Mar 2, 2021

@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.

0 replies

ibiqlik · 2021-12-08T09:24:31Z

ibiqlik
Dec 8, 2021
Author

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

0 replies

AllanOricil · 2021-12-10T11:44:52Z

AllanOricil
Dec 10, 2021

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

0 replies

corentingiraud · 2022-05-31T15:42:24Z

corentingiraud
May 31, 2022

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

4 replies

ibrahima Jun 30, 2023

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 Jun 30, 2023

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 Jun 30, 2023

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

johnboiles Jun 30, 2023

Great news

kamilmodest · 2022-12-20T15:21:49Z

kamilmodest
Dec 20, 2022

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.

1 reply

JamesMGreene Mar 22, 2023
Collaborator

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 · 2022-12-25T21:09:53Z

psionic-k
Dec 25, 2022

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.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GitHub Community

GITHUB_SHA not the same as the triggering commit #26325

{{title}}

Replies: 8 comments 6 replies

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

GITHUB_SHA not the same as the triggering commit #26325

Replies: 8 comments · 6 replies

ibiqlik May 4, 2020 Author

ibiqlik Dec 8, 2021 Author

JamesMGreene Mar 22, 2023 Collaborator

Replies: 8 comments 6 replies

ibiqlik
May 4, 2020
Author

ibiqlik
Dec 8, 2021
Author

JamesMGreene Mar 22, 2023
Collaborator