Repository navigation
Keep every workflow_run step on the commit that passed the one before - #72
Conversation
A workflow_run event checks out the latest main commit, not the commit the upstream workflow tested. Check out workflow_run.head_sha in test, build and release, and run only while it is still the tip of main. A stale chain is then skipped, and the newer commit releases through its own chain. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes Reviewed commit selection and job conditions in the test, build, and release workflows.
- Pinned checkout: Each
workflow_runjob checks out the source run'shead_sha. - Stale run checks: Each job requires a successful source run whose SHA matches the receiving run's
github.sha. Existing Actions API records confirm that workflows with all jobs skipped have conclusionskipped, so they do not pass the next success condition. - Pull request behavior: The
testandbuildjobs retain their pull request path. An empty checkoutrefretains the default pull request checkout.
The five existing PR checks passed. I checked the GitHub event contracts and Actions API records. I did not start a new main workflow chain.
gpt-6.1-sol | 𝕏
Workflow concurrency applies before job conditions, so a stale or failed upstream event could cancel or replace the run for the current commit and then skip its own jobs. Give those events a group of their own. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes Reviewed the concurrency changes in 2aa504f, since the prior review at cee9099.
- Isolated skipped runs: Changed
test,build, andreleaseto use a separategithub.run_idgroup for stale or unsuccessfulworkflow_runevents. - Preserved active-run controls: Kept successful current-SHA events and pull request checks in their previous ref-based groups. Retained cancellation in
testandbuild, and serialization without cancellation inrelease.
All three changed workflows passed local actionlint validation. All five PR checks passed. I checked the expressions against GitHub's documented concurrency rules; I did not start a new main workflow chain.
gpt-6.1-sol | 𝕏

On
main,test,buildandreleaseeach start from the previous workflow throughworkflow_run. In aworkflow_runrun,actions/checkoutdefaults togithub.sha, which is the latest commit onmain, not the commit the previous workflow checked. Ifmainmoves between steps, or an older run is re-run,buildcan verify a different commit thantestdid, andreleasecan publish a commit that never passed both.workflow_runjob checks outgithub.event.workflow_run.head_sha.github.sha, the tip ofmain. A run that passes this check has the tested commit as its ownhead_sha, so that SHA carries through to the next step. A stale chain ends asskipped, notsuccess, so the next step does not start, and the newer commit releases through its own chain.Pull request runs are unchanged: the added expressions are empty on
pull_request.Pullfrog raised this on faultier#89 and sakuga#21. This PR applies the same fix here.
🤖 Generated with Claude Code