fix(ci): let the complexity delta account for itself — the receipt could not see it - #31
Merged
Merged
Conversation
…uld not see it The liveness control shipped in #25 had this workflow's own failure mode inside it. The complexity receipt proved liveness with `ruff --show-files`, which counts the files ruff would enumerate — true whether or not the DELTA step ran. So a delta that bailed on an unresolvable merge base emitted a `::notice`, exited 0, and left a green `measured` receipt behind. On a PR the delta IS the point of that job, and it could go quiet while the gate reported success. The delta now records its own outcome to c901-delta.env, written LAST on the success path so its absence proves the step died, and written explicitly on the merge-base bail path so a skip is distinguishable from a crash. The receipt rules on it: PR + delta ran -> measured, evidence names the merge base and the base/head finding counts PR + marker missing -> failed, "did not complete" PR + delta bailed -> failed, carrying the recorded reason cron / dispatch -> measured, "the PR delta does not apply on <event>" That last row is deliberate. On a non-PR event the delta legitimately does not run and the whole-repo triage IS the measurement; failing there would fire on good news, and a check that fires on good news gets muted -- which would leave us worse off than before. TWO BUGS FOUND BY EXECUTING THE RECEIPT SHELL, not by reading it: * The reason was silently discarded. The receipt SOURCES the marker, and the reason was written unquoted, so bash parsed a value containing spaces as a command and left the variable unset. The failure reported "no reason recorded" -- throwing away the only useful diagnostic, on the exact path that exists to provide one. Now single-quoted, and asserted. * My own new test was vacuous. It asserted the marker appeared at least twice in the step, which the bail path satisfies on its own (it writes two lines), so deleting the SUCCESS-path marker passed. Caught by mutating the workflow and watching the assertion fail to go red. It now partitions the step at the c901_delta.py call and requires a marker on both sides. All four receipt paths were executed against the extracted shell; all four negative probes on the new assertions now go red.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The liveness control shipped in #25 had this
workflow's own failure mode inside it.
The complexity receipt proved liveness with
ruff --show-files, which counts the files ruff wouldenumerate — true whether or not the delta step ran. So a delta that bailed on an unresolvable merge
base emitted a
::notice, exited 0, and left a greenmeasuredreceipt behind. On a PR the delta isthe point of that job, and it could go quiet while the gate reported success.
The fix
The delta records its own outcome to
c901-delta.env— written last on the success path, so itsabsence proves the step died, and written explicitly on the bail path, so a skip is distinguishable
from a crash. The receipt rules on it:
measured— evidence names the merge base and base/head finding countsfailed— "did not complete"failed— carries the recorded reasonmeasured— "the PR delta does not apply on<event>"That last row is deliberate: on a non-PR event the delta legitimately doesn't run and the whole-repo
triage is the measurement. Failing there would fire on good news, and a check that fires on good news
gets muted — worse than not having it.
Two bugs found by executing the receipt shell, not reading it
sources the marker, and the reason was writtenunquoted — bash parsed a value containing spaces as a command and left the variable unset. The
failure reported "no reason recorded", throwing away the only useful diagnostic on the exact path
that exists to provide one.
bail path satisfies alone (it writes two lines) — so deleting the success-path marker passed.
Caught by mutating the workflow and watching the assertion fail to go red. It now partitions the
step at the
c901_delta.pycall and requires a marker on both sides.Verification
All four receipt paths executed against the shell extracted from the YAML; all four negative probes on
the new assertions go red. 55 quality tests pass ·
ruff checkclean · zizmor real exit 0 · YAML valid.Advisory-only as before: no write scope on any job, no new required check.