GitHub Community
GITHUB_SHA not the same as the triggering commit #26325
-
|
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 Can someone please shed some light for me? |
Beta Was this translation helpful? Give feedback.
Replies: 8 comments 6 replies
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Ah missed that detail, thanks for pointing it out for me. Can get the commit I want using: Or (not tested) https://github.com/actions/checkout#checkout-pull-request-head-commit-instead-of-merge-commit |
Beta Was this translation helpful? Give feedback.
-
|
Thanks ! it is really helped ! |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
😆 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? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, your code helped me actually haha |
Beta Was this translation helpful? Give feedback.
-
|
I can confirm that |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I have this question too. Is |
Beta Was this translation helpful? Give feedback.
-
|
The event payload won't change if you rerun the workflow. |
Beta Was this translation helpful? Give feedback.
-
|
Great news |
Beta Was this translation helpful? Give feedback.
-
|
I want to have one workflow for both: I mean case when my workflow starts with: on:
pull_request:
push:
branches:
- main
- developIf I use |
Beta Was this translation helpful? Give feedback.
-
|
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 }} |
Beta Was this translation helpful? Give feedback.
-
|
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 I ran into this after force pushing a branch. CI works 99 times out of 10 and then suddenly this 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. |
Beta Was this translation helpful? Give feedback.
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.