Weird Github SHA on an action

Hi folks,

I’m seeing a weird GITHUB_SHA that breaks the CI builds. Here is the action in question: https://github.com/mull-project/mull/pull/739/checks?check_run_id=941955256
There is a number of steps, first, the checkout says the following:

HEAD is now at 3b3b9b4 Merge 5cae518686005d7cc12968e452105a30a2b94d01 into 4314d1734c365dcb4f8247a6106fb02a896e41f1

Then the step “For debugging” prints env variables and there I see the following SHA:

GITHUB_SHA=7318c1c8750fde75becae1467aecd22a7678b4ee

Later on, the script is trying to check out the GITHUB_SHA commit, and obviously fails.

The question is, therefore: what’s the GITHUB_SHA points to and how is it supposed to be used?

Just in case, a month or so ago everything worked correctly, but now it fails for an unknown reason.

Any hints would be greatly appreciated!

Cheers,
Alex.

@alexdenisov,

what’s the GITHUB_SHA points to and how is it supposed to be used?

The GITHUB_SHA (aka github.sha) is the commit SHA that triggered the workflow.
In the workflow runs on pull request trigger, the GITHUB_SHA points to the pull request merge commit generated on the pull request merge branch.
When using checkout action in the workflow, by default the action will checkout the GITHUB_SHA (git checkout $GITHUB_SHA).
When checkout the pull request merge commit, the checkout action should say like as below:

HEAD is now at ${{ github.sha }} Merge ${{ github.event.pull_request.head.sha }} into ${{ github.event.pull_request.base.sha }}

In your case, if the GITHUB_SHA actually is ‘7318c1c8750fde75becae1467aecd22a7678b4ee’, the log should like this:

HEAD is now at 7318c1c Merge 5cae518686005d7cc12968e452105a30a2b94d01 into 4314d1734c365dcb4f8247a6106fb02a896e41f1

It is very strange that the HEAD point to the checked out commit is not same with the GITHUB_SHA in your workflow.
I tested and tried, but did not reproduce the issue. Everything was OK on my side. And I can checkout the same GITHUB_SHA multiple time in a same job in the workflow (see example here).

Please check with the following ways to see if the problem can be solved:

  1. Use the ‘ref’ key to specify the commit SHA you want to checkout on the checkout action.
- name: Checkout
  uses: actions/checkout@v1
  with:
    ref: ${{ github.sha }}
    submodules: true
  1. Use the latest version of the checkout action (Checkout V2).
- name: Checkout
  uses: actions/checkout@v2
  with:
    submodules: true

OR

- name: Checkout
  uses: actions/checkout@v2
  with:
    ref: ${{ github.sha }}
    submodules: true

Checkout@v2 fails with another error:

##[error]Input ‘submodules’ not supported when falling back to download using the GitHub REST API. To create a local Git repository instead, add Git 2.18 or higher to the PATH.

I’ll probably try to install newer git before checking out, but there is some more confusing info.
In the other job (https://github.com/mull-project/mull/pull/739/checks?check_run_id=941955311) I also print the contents of the $GITHUB_EVENT_PATH and the action there is synchronize.

From the outside, the issue looks like a severe bug with some parts messed up behind the scenes :frowning:

@alexdenisov,

From the outside, the issue looks like a severe bug with some parts messed up behind the scenes

Not sure if there is a bug. I tested and tried on my side, but never reproduced the problem.
I have created an issue ticket (actions/checkout#318) to help you report this problem to the appropriate engineering team for further investigation and evaluation.

You can follow this issue ticket and add your comment in it.

Try checkout v2. On a pull request it fetches the specific SHA.

V1 fetched the ref (refs/pull/…).

Not sure if there is a bug.

@brightran there is a weird SHA that comes out of nowhere. I guess this is a bug, but I don’t really want to argue.

@ericsciple I’m trying checkout@v2, but there are two issues:

  1. It gives me hard times by requiring git 2.18
  2. even if it works, the bug I describe here is still there and not fixed.

@alexdenisov,

Thanks for your reply.
We will continue investigating this issue with the engineering team.
Sorry for the inconvenience caused to you.