chadtmiller.com/knotless
git that lives in your Atmosphere account
1
10
Deploy, release and publish-lexicons wait for main's checks holding no job
Merged Approved
This moves deploy, release and publish-lexicons from waiting for main's seven checks in a step to naming them in after. I found nothing that must change.
- Semantics.
afteris documented indocs/reference/workflows.mdand in the runner (crates/knotless-run/src/lib.rs). A run waits for the named checks at its own commit and holds no job. It is filed failed without running if one fails or is cancelled. A named workflow with no check at that ref is skipped, and the log says so. That is whyreleaseandpublish-lexiconsstill work when asked on a non-main branch, and why the newpublish-lexiconscomment ("waits for those of them that ran there") is right. - Deploy. The removed
checks doneandchecks passsteps were the only places that dropped the candidate on a failed check. Now a failed check means the run never starts, so no candidate is built and there is nothing to remove. The~/.movedandunless-movedsupersede logic around build andupis left intact. The README and the header comment match the new flow. - Lockfile. Removing the
wait-for-checks@2pin from.knotless/uses.lockis consistent, because no workflow uses it any more. - Checks. At review time the pull's own checks were still queued or running (
checkwas running, andtest,webanddocswere queued). I judged the pull from the diff alone.
A small leftover, which doesn't block this: AGENTS.md says "deploy.yml still runs, and waits for them as ever". That is still true, but "waits" now means after.
All checks have passed
9 passed, 1 skipped
Merged as 0e8d3c5
What changes
deploy,releaseandpublish-lexiconsname main's seven checks inafterinstead of waiting for them in a step. Each is held back, holding no job, until the checks pass at its commit, and is filed failed without running if one fails. The waiting steps are gone: deploy'schecks doneandchecks pass, and thewait-for-checksstep in the other two, so its pin leaves.knotless/uses.lock.deploy/README.mdsays how a deploy now runs.Why
The runner that checks main runs two jobs at once. On the push that landed pages,
deployandpublish-lexiconsstarted first and took both, each waiting in a step fortest,webandshots, which then could not get a job until those waits ran out, 25 minutes on, failing the deploy. Withafter, waiting costs no job.The cost is that deploy builds its image after the checks rather than while they run: a push goes live a couple of minutes later than it did when nothing was stuck.
🤖 Generated with Claude Code