chadtmiller.com/knotless

Switch repository

Loading…

What changes

A pull's or batch's check that its paths left out is now kept, as a run that passed is. The push to main at the same tree takes it without running the workflow, but only once the push's own run of that workflow passed at the batch's base. Its log says it passed at the same tree, and that the run it took was skipped.

Why

Every push to main from the queue reran web and shots from scratch whenever the batch changed nothing under web/, though the batch had checked that very tree. On the 0.7.0 release this deadlocked prod's two jobs. deploy and release took both, and each waits inside its job for all seven checks, so web and shots sat queued until release's 25-minute wait gave up. With this, a push from the queue finds all seven passed at once.

Requiring the base's own pass keeps the skip honest. It means nothing the workflow reads changed from a main that passed it, not merely from one that ran it.

It leaves a push no batch checked, such as a forced merge, as it was. Its checks run for real, and two workflows waiting in both jobs can still starve them. That needs runs that wait for other workflows to take no job, as their own change.

How it was checked

a_merged_pull_passes_its_push now has a web workflow with paths. A pull that leaves web/ out passes the push at its tree without running it, its log saying so. After a main whose web failed, the next pull's push runs web. The rest is left to CI.

Changeset: none

Shortcomings

A push takes the skip only when the base's own run has passed by the time the push is checked. One still running then runs the workflow, as before.

🤖 Generated with Claude Code

This lets a pull's or batch's path-skipped check be kept as a passed run, so the push at the same tree can reuse it. The push takes it only when the push's own run of that workflow passed at the batch's base, which passed_on looks up by rkey. I read the keep_passed call site, the reused change and the rkey construction, and found nothing wrong. A skipped run has no log, so the copied log falls back to its skipped reason. The existing trust checks in keep_passed still apply. The test covers the skipped path, the failed-base path, and the log text. The design doc is updated to match. I did not check CI results.

This round adds a build fix and a merge of main on top of the code I approved before. The change is the same: a pull's or batch's path-skipped check is kept as a passed run. The push at that tree reuses it only when the push's own run of that workflow passed at the batch's base. The new commits touch nothing else in the diff, and I found nothing new to flag. The check, docs, web, shots, lexicons and e2e checks have passed. The test check was still running when I looked, so I haven't seen the new web cases in a_merged_pull_passes_its_push pass. That check should confirm the build fix.

This round's one new commit changes the copied log line for a reused skip from ==> skipped: {why} to ==> {why}. The stored reason already begins with skipped:, as the check records show, so the old text would have said "skipped" twice. The fix is right, and the rest of the change is as I approved it before. The web, shots, lexicons and e2e checks have passed. test, check and docs were still queued or running when I looked, so I haven't seen the a_merged_pull_passes_its_push cases pass. Wait for test before merging.