This is the result of adding the HEAD checkout:

Run actions/checkout@v2
    attempting to correct wrong ref checkout
Run actions/checkout@v2
Syncing repository: b*ner-cmd/CrepeMC
Getting Git version info
Deleting the contents of '/home/runner/work/CrepeMC/CrepeMC'
Initializing the repository
Disabling automatic garbage collection
Setting up auth
Fetching the repository
Determining the checkout info
Checking out the ref
/usr/bin/git log -1
commit 0881a425a4d76a35aa274e130a1bc69963d825da
Author: Dimelo Waterson <54084132+b*ner-cmd@users.noreply.github.com>
Date:   Sat Jun 27 16:48:38 2020 -0500
attempting to correct wrong ref checkout

Run git checkout HEAD^

HEAD is now at f1db0f6 Template updated!

Run git checkout HEAD^

Note: switching to 'HEAD^'.
You are in 'detached HEAD' state. You can look around, make experimental

changes and commit them, and you can discard any commits you make in this

state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may

do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at f1db0f6 Template updated!

So checkout initially grabbed the “wrong” ref (“Attempting to correct”), then the HEAD checkout pointed to the correct subsequent ref (“Template Updated”). Unfortunately I’m not sure if it did what I wanted because the template didn’t have a functional change. But it looks like it worked? Is this the answer?

Unfortunately I’m not sure if it did what I wanted because the template didn’t have a functional change. But it looks like it worked? Is this the answer?

If there are no other team members or workflow which push new changes at the time gap after job1 pushed the changes and before job2 checkout operation, you could use checkout HEAD to get the commit pushed in job1.
The ref for actions/checkout action defaults to the reference or SHA for that event which triggered the workflow. As those two jobs are in the same workflow, so in defaults, the reference or SHA for checkout steps in two jobs are the same. You need to add some other settings to checkout what you need.

You need to add some other settings to checkout what you need.

This is essentially the basis of my question. I’m reassured to hear that checkout HEAD is a solution. However, I’m still trying to reach the best solution. As you said, that would preferably be to checkout the correct reference (the one pushed by job 1).

My next step would be to grab that reference somehow and then store it, then somehow reference it when using actions/checkout, but I don’t see a way to checkout a specific reference. Two ways I’ll probably try next:

1. Use git checkout <commit> instead of git checkout HEAD^ after storing the correct commit ref or SHA

2. Set the environmental variable GITHUB_SHA, GITHUB_REF, or both if necessary at the beginning of Job 2 to make it appear that the reference that triggered the workflow was the one created in Job 1, not before Job 1.

As always, I’m open to more elegant, less hacky, solutions

You could store the SHA ref in a file, upload the file as an artifact, and grab it in the next job. According to the documentation you can check out a specific commit using the ref parameter for actions/checkout.

I marked the post with a complete example as the solution, but the answer to my question required both halves:

1. Use with: ref: to pass the correct SHA directly to actions/checkout
2. Use job needs output instead of environment variables to pass the value between jobs

Thank you both for the help. I also found the job needs output page, but was trying to use it with git checkout, which was messy and error-prone. Returning to read your answers resolved the issue perfectly.

Edit: For completeness, I forgot to mention that I used git log -1 --format="%H" in testing instead of git rev-parse HEAD, with no ill effects, although the latter is probably superior for automation.

Thanks for the nod in the issue/commit comments! 🙂

Another solution to ref is to use git pull --all