GITHUB_SHA is the prior commit's hash, not the current commit's

[actual-nh]

What article on docs.github.com is affected?

https://docs.github.com/en/actions/reference/environment-variables

What part(s) of the article would you like to see updated?

See https://github.laiyagushi.community/t/commit-sha-by-github-action-always-one-behind-the-commit-sha-displayed-in-github-gui/17979; GITHUB_SHA is not the actual commit being tested. It is the previous commit (which is rather useless for coordination purposes with other sites; see #4422 for more on this, including an example of the lack of correspondence).

Additional context

I'd submit a PR, but I don't think it would be advisable - I am currently a bit irked about all this. Of course, if anyone has problems rewriting it, getting someone to fix it so it works the way it currently reads is an alternative 😁

[janiceilene]

Thanks so much for providing that additional information @actual-nh! I'll triage this for the team to take a look 👀

[lee-dohm]

Hello @actual-nh 👋 Thanks for reaching out.

In order to properly evaluate this and ensure that we're documenting the right things, we need to be certain that we're understanding what the exact problem is here. Therefore, what we need from you is to give us precise steps to reproduce the behavior you're seeing. For more information on the kind of thing we're going to need to follow up on this, you can check out this blog post I've written on bug reports and the importance of repro steps.

Unfortunately, as this issue, in its current state, isn't actionable we'll need to close it without that extra data.

Thanks for all your patience and interest in improving the GitHub Documentation.

[actual-nh]

OK:

• Fork a repository that uses a shell script, call it build.sh, to run builds and/or testing in Github Actions, including on PRs.
• Edit the build.sh script, adding a comment "# GITHUB_SHA test 1".
• Create a branch with this commit; let us call it "GITHUB_SHA test 1".
• Edit the built.sh script, adding a line echo "GITHUB_SHA: ${GITHUB_SHA}" someplace where it will be run. The commit should be "GITHUB_SHA test 2".
• Do a PR for this branch.
• Examine the Github Actions log for "GITHUB_SHA".
• Once found, examine after GITHUB_SHA for the contents of this environmental variable.
• Note that (unless the bug has been fixed in the meantime) the variable does not start with the same hexadecimal number as does the commit, found near the top of the screen after "GITHUB_SHA test 2". (It is likely that it is the one associated with "GITHUB_SHA test 1".)

@lee-dohm: Is further information needed? (Expanded a bit to say more about investigating what the SHA in question actually is.)

[lee-dohm]

Do you have a publicly forked repository where this has been done so that I can examine it? There's still a lot of open questions here, especially around the specific construction of the Actions workflow ... which can completely change the behavior of GITHUB_SHA depending on how it is constructed.

I did some digging, and if this is the behavior you're seeing, then this is the expected behavior. This is because, as the documentation on the page you link to above states, GITHUB_SHA refers to "the SHA of the commit that triggered the workflow". If you look at the more detailed documentation on the page outlining all of the possible events that can trigger workflows, the pull_request event states that the SHA of the commit that triggers the workflow on pull_request events is:

Last merge commit on the GITHUB_REF branch

This is due to the internals of how GitHub manages pull requests. Since this behavior is specific to pull requests and doesn't belong in the general page that you're mentioning and is already documented in the page covering the specific pull_request event, I don't see that there's any change that needs to be made.

Thanks again for reaching out!

[actual-nh]

@lee-dohm: Then exactly why does travis have the correct commit id available? Sorry, this is not the expected behavior.

[lee-dohm]

Unfortunately, I can't speak to how or why Travis operates the way that it does. However, from what I can tell, the documentation does reflect the current behavior of Actions.