checkout: Checking out wrong commit?

This looks quite serious (allows to sneak not validated code as valid)

@ericsciple is there any specific timeline for this?

I believe this is a dupe of #237, please see my comment here: https://github.com/actions/checkout/issues/237#issuecomment-667158637

@ericsciple which issue should we follow this one (#299) or #237?

I was able to use the following work-around:

[... trimmed ...]
      - name: Checkout code
        uses: actions/checkout@v2
        with:
          # Check out pull request's HEAD commit instead of the merge commit to
          # work-around an issue where wrong a commit is being checked out.
          # For more details, see:
          # https://github.com/actions/checkout/issues/299.
          ref: ${{ github.event.pull_request.head.sha }}
[... trimmed ...]

I had the same problem in the pull-request.

Fix with:

- uses: actions/checkout@v2
  with:
    ref: ${{ github.event.pull_request.head.sha }}

Beware: this checks out the current head of the branch, whereas by default the action checks out the merge commit. By using this workaround, you will no longer catch conflicting changes in the base branch.

Is there a way to check out the correct merge commit without race conditions? There’s the merge_commit_sha field, but the docs indicate that that may be null if mergeability has not yet been computed.

@andymckay I was introducing CI in one branch and it started complaining about code from another, but they were mutex.

I had a couple of branches running at that point so don’t want to send it in and it turns out it was PEBKAC so I don’t waste your time. If it happens again, I’ll be sure to let you know. Thanks.

We just ran into what I think is another instance of this issue in https://github.com/DFHack/scripts/runs/910104637?check_suite_focus=true#step:4:375 This check ran on https://github.com/DFHack/scripts/commit/5177a127b32631fbcedc4b0e93e0c5c05a124388, but ended up running on a merge between master and the previous commit on that branch (https://github.com/DFHack/scripts/commit/1ec3d9b1a14c6b39b1bf0b907108a3e313eed955, as seen in the actions/checkout output), which produced a lot of irrelevant errors that the newer commit was intended to address. This issue repeated itself when we re-ran the check, so it appears to be reproducible in this case, but I’m not seeing an obvious reason why - the newer commit in that PR was pushed well after the checks run on the older commit failed, and we haven’t seen this in other PRs. Update: we’ve seen this in at least two PRs so far.

About 2 minutes after re-running the check reproduced the issue, I ran this locally, which resulted in fetching a correct merge, so I’m pretty sure the issue is on the action’s end:

$ git fetch origin refs/pull/159/merge
$ git show FETCH_HEAD 
commit 5be19d326c828ac38ce307eb6db068e691504a7e
Merge: ad67c79 5177a12