ci(ratchet): let the corpus ratchet print its verdict instead of a bare exit code (Closes #2314) - #2315
Merged
Merged
Conversation
…re exit code The step's `rc=$?`, `sed` and `exit $rc` are dead code. A `run:` block with no `shell:` key executes under `bash -e`, so the failing `t27c` aborts the step where it stands and those three lines run only when the ratchet passes -- only when there is nothing to read. The job log has therefore been `##[endgroup]` followed immediately by `##[error]Process completed with exit code 1.` for the step's entire history, while `Explain a failure` annotated "See the Ratchet section above" for a section never printed. The verdict survived only in the uploaded artifact, at 14-day retention. `|| rc=$?` moves the failure off the `-e` abort path. A missing verdict now prints the log tail rather than falling back to a bare exit code a second time. Verified off CI by running the YAML-parsed block under `bash -e` against a stub `target/release/t27c`: master's block emits zero bytes on both streams and exits 1, reproducing the job log; the new block prints the Ratchet section and exits 1, prints it and exits 0 on success, and prints the tail and exits 101 on a panic before the verdict. The outcome is carried through unchanged on all three paths. This does not turn the check green and must not: the ratchet is red because two specs now reach `parse-no-discard` and `no-vacuous-invariant`, which report 123 discarded top-level tokens and 10 declared-but-unlowered invariants. Whether to bless that in the ledger or fix the specs is a maintainer's decision and is left open. Closes #2314
gHashTag
enabled auto-merge (squash)
August 20, 2026 10:08
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
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.
Closes #2314
The check is red, and the log is empty by construction
corpus-ratchethas failed on every master run since #82 (e7ef72bfb,2026-08-19T21:43:12Z). Job
96381621406at master head9068cf49d, lines 6947 and6948, consecutive, with nothing between them:
Explain a failurethen annotatesCorpus ratchet failed :: See the Ratchet section above.-- a section that has never once been printed.Why
The step on master:
A
run:block with noshell:key executes underbash -e. The failingt27caborts the step where it stands, so
rc=$?, thesedand theexit $rcexecuteonly when the ratchet passes -- only when there is nothing to read. On the single
path they were written for, they are dead code.
Verified off CI, both directions
The
run:block was pulled out of the YAML by the parser and handed a stubtarget/release/t27c. Master's block, against a stub that prints a Ratchet sectionand exits 1:
Zero bytes on both streams, exit 1 -- the job log, reproduced. That is the negative
control: the defect is demonstrated, not inferred.
This PR's block, same harness, three stubs:
t27cError: RATCHET FAILEDtail -40The exit code is carried through unchanged on all three paths, so this changes what
the job says and never what it concludes.
|| rc=$?was chosen overset +eor ashell:override because it moves exactlyone command off the
-eabort path and leaves the rest of the step strict.This does not make the check green, and must not
The ratchet is red for a real reason. Until now it lived only in
ratchet.loginsidethe
corpus-ratchet-logartifact -- 287,391 bytes, 14-day retention:e7ef72bfbmade two specs parse, which un-blocked the phases behindparse:The mechanical route exists and needs no cap raise -- drop the 3 fixed rows, add the
2 new ones, land at 220 under the 221 cap, then lower
max_entries. It is nottaken here, because it would bless a spec that declares ten invariants and checks
none of them. Bless-versus-fix is a maintainer's decision, left open on #2314.
corpus-ratchetis not a required context, so this PR can merge while its ownratchet job is red -- which is the point. Its job on this PR runs the new step
(
pull_requestworkflows execute from the PR head), so this PR's own red ratchet runis the live demonstration: it will print the verdict above instead of nothing.
Diff
.github/workflows/corpus-ratchet.ymldocs/NOW.mdNo threshold moved, no assertion deleted, no baseline widened, no skip added.