checkout: checkout action performing merge commit from incorrect base SHA
We’re observing actions/checkout
creating merge commits based on the repo’s latest master SHA, rather than github.event.pull_request.base.sha
from the event that initiated the action.
This causes different merge commits across jobs within a single workflow. This is despite GITHUB_SHA
, github.sha
, github.event.pull_request.head.sha
, and github.event.pull_request.base.sha
being identical for both jobs.
This happens because a new commit was added to master between the two job runs, but the observed behavior is still surprising given that both jobs are given identical environment variables and Github event data.
Identical environment between jobs
GITHUB_REF=refs/pull/14/merge
GITHUB_SHA=aa0ad9298d3b4e43eb7f56bdb33af0609193dba7
Abridged ${{ github }}
context:
GITHUB_CONTEXT: {
"ref": "refs/pull/14/merge",
"sha": "aa0ad9298d3b4e43eb7f56bdb33af0609193dba7",
"head_ref": "siggy/workflow-testing",
"base_ref": "master",
"event": {
"pull_request": {
"base": {
"ref": "master",
"sha": "891c8c550cf9f3890c612e4ef5ba77fbc93ec642",
},
"head": {
"ref": "siggy/workflow-testing",
"sha": "74460e62efc34fe80862f684dad06f41f55dacc1",
},
}
},
}
Job 1
git checkout --progress --force refs/remotes/pull/14/merge
...
HEAD is now at aa0ad929 Merge 74460e62efc34fe80862f684dad06f41f55dacc1 into 891c8c550cf9f3890c612e4ef5ba77fbc93ec642
Full output: https://github.com/siggy/linkerd2/runs/207435287#step:2:1007
Job 2
git checkout --progress --force refs/remotes/pull/14/merge
...
HEAD is now at 7efd2d0b Merge 74460e62efc34fe80862f684dad06f41f55dacc1 into 324483a653c7c09a350bc2a782080d6ea0ae533d
Note that Job 2 has created merge commit 7efd2d0b
based off of the most recent master commit 324483a653c7c09a350bc2a782080d6ea0ae533d
, despite these SHAs not appearing anywhere in the environment variables or event data.
Full output: https://github.com/siggy/linkerd2/runs/207437496#step:2:1014
State of master
Note that the above event data references the 2nd most recent commit to master, as that was the state of master when the workflow was triggered:
$ git log --pretty=oneline | head -n2
324483a653c7c09a350bc2a782080d6ea0ae533d master branch testing
891c8c550cf9f3890c612e4ef5ba77fbc93ec642 Merge remote-tracking branch 'upstream/master'
with
/ref
config
Note that setting ref: ${{ github.sha }}
or ref: ${{ github.ref }}
had no effect:
sha
https://github.com/siggy/linkerd2/pull/14/checks?check_run_id=207481400#step:2:3
- name: Checkout code
uses: actions/checkout@v1
with:
ref: ${{ github.sha }}
Run actions/checkout@v1
with:
ref: 17c77866218c23d4b2a47221ccd9aff78a5d7172
clean: true
...
git checkout --progress --force refs/remotes/pull/14/merge
...
HEAD is now at d6ae7796 Merge 80e75c911dbd20e9b1226d7854818843b037dc1a into ae31e8838e171e60e1cd2fa9ad54070fcb741025
ref
https://github.com/siggy/linkerd2/pull/14/checks?check_run_id=207488293#step:2:3
- name: Checkout code
uses: actions/checkout@v1
with:
ref: ${{ github.ref }}
Run actions/checkout@v1
with:
ref: refs/pull/14/merge
clean: true
...
git checkout --progress --force refs/remotes/pull/14/merge
...
HEAD is now at eb786159 Merge 8a33bbfb6ad62902926b1449c2b9703433da6450 into ae31e8838e171e60e1cd2fa9ad54070fcb741025
Previously reported in the Community Forum
…but upon further inspection of workflow environment variables opted to create an issue in this repo.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 12
- Comments: 16 (5 by maintainers)
Commits related to this issue
- Speed up and make happo-ci more robust when HAPPO_IS_ASYNC Support for the HAPPO_IS_ASYNC env variable was recently added to happo.io. So far, it's only been affecting `happo run` and `happo compare`... — committed to happo/happo.io by trotzig 4 years ago
- Size reports: Fix parent SHA race #### Problem For a GitHub PR, the actual parent may be different from the commit given by `github.event.pull_request.base.sha` (see https://github.com/actions/check... — committed to kpschoedel/connectedhomeip by kpschoedel 3 years ago
- Size reports: Fix parent SHA race (#11841) * Size reports: Fix parent SHA race #### Problem For a GitHub PR, the actual parent may be different from the commit given by `github.event.pull_requ... — committed to project-chip/connectedhomeip by kpschoedel 3 years ago
- Fix master merge to working branch on pre-commit autofixes Details: https://github.com/actions/checkout/issues/27#issuecomment-889317591 — committed to antonbabenko/pre-commit-terraform by MaxymVlasov 3 years ago
- Size reports: Fix parent SHA race (#11841) * Size reports: Fix parent SHA race #### Problem For a GitHub PR, the actual parent may be different from the commit given by `github.event.pull_requ... — committed to kpschoedel/connectedhomeip by kpschoedel 3 years ago
- Size reports: Fix parent SHA race (#11841) * Size reports: Fix parent SHA race #### Problem For a GitHub PR, the actual parent may be different from the commit given by `github.event.pull_requ... — committed to raqbit/connectedhomeip by kpschoedel 3 years ago
- ci: use PR's HEAD in guix workflow (#5416) ## Issue being fixed or feature implemented Our guix workflow creates a merge commit instead of using HEAD from a PR itself which is why commit hash is di... — committed to dashpay/dash by UdjinM6 a year ago
and:
Yes, this is the intended default behavior. The goal is to validate that the pull request will build and test against what it would be merged into. Continuous integration builds need to take into account what they’ll be merge into, not the state of the repository when they were created. This prevents you from merging a commit that breaks master but “worked on my machine”.
If your goal is not to validate the CI but to do some fixups (ie, automatic updates from linting) then I agree that you would not want to check out the merge commit but to actually
If you really want to validate the pull request as it was actually sent, and not what would be produced by a merge into master (ie, in isolation of the master branch), you can specify the ref to checkout:
However, I strongly encourage you not to make this a separate workflow - one workflow that lints and updates the PR if (and only if) it made some changes, and then a second workflow that does a build and test on the merge produced into master for verification.
Thanks, @siggy, for the clarification. We’ll give this some thought.
@ethomson Appreciate the detailed reply. Testing a PR merged into master is in fact what we want, not
github.head_ref
.Our core issue is that our workflow that executes
actions/checkout
across multiple jobs, and if master changes between those jobs,actions/checkout
yields different copies of the repo.This is problematic because, for example, a job in our workflow builds docker images versioned as
docker-image:git-sha-foo
, and then a subsequent job tries to deploydocker-image:git-sha-bar
.The result is every time we merge master, most currently-running CI workflows fail. Here’s an example, note
actions/checkout
yielding different repo SHAs within a single CI workflow: https://github.com/linkerd/linkerd2/runs/238047516#step:2:1142 https://github.com/linkerd/linkerd2/runs/238049216#step:2:1142Is there any plan to open source this action? We’d love to just submit a PR to better illustrate the issue. Failing that, we may write our own checkout action, but we’re concerned about potential rate limit issues.
Any guidance is much appreciated, thanks.
@siggy
actions/checkout@v2
fixes the race condition. For PRs, the individual SHA is now fetched.We’re also running into this issue. – Basically under the hood, Github Actions/Checkout is checking out this phantom Merge Commit, when I look at other environment variables like
GITHUB_SHA
they actually point to this fake commit – and the commit claims to be from me! (but it’s not signed/verified like my other commits are).