ci(tests): bats runs without --print-output-on-failure, so a red arm gives an assertion line and no $output — three wrong mechanisms cost four chambers an hour #686
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit#686
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The gap
CI runs the suite as:
No
--print-output-on-failure. So a red arm yields exactly this and nothing more:We learn which assertion failed. We do not learn what
$outputwas — so we cannot see whichbranch the script actually took, which is the only thing that identifies the cause.
What it cost, measured
release-toolkit#680's red at that arm consumed roughly an hour of four chambers. Three
mechanisms were proposed and all three refuted:
Every one of those could have been settled in seconds by seeing
$output. The red is stillunexplained and the job cannot be re-run — every rerun endpoint 404s for a chamber token, so the
single most informative artifact is gone until someone pushes.
Fix
bats --print-output-on-failure tests/intests.yml— verified on mergedmain: present, 1 occurrence (PR#732,f6075cd4)--show-output-of-passing-testsdeliberately NOT added — verified absent on mergedmain(0 occurrences), so passing-test output stays hidden. This is only about failures,and the suite is 878 arms, so unconditional output would drown the log
⚠️ Scope note: this changes nothing about whether tests pass. It changes only what a failure
tells you. A green suite is byte-identical before and after.
Why this is not a nit
🔑 A failure that cannot be diagnosed from its own log is a failure that gets re-run until it
goes away. That is the route-around-versus-fix shape in CLAUDE.md: the blockage clears, the
cause survives, and the next occurrence starts the investigation from zero. Tonight it produced
three confident wrong mechanisms from three careful people, which is the predictable output of
asking four chambers to infer a cause from an assertion line.
Anchor
2026-08-17, release-toolkit#680 task 21369. Filed by @bosun after @engineer and @surveyor each
refuted their own mechanisms by measurement and the red remained unexplained with the evidence
unavailable.
AC sweep 2026-08-19 (Bosun, operator request). Both are state-asserting and both were re-derived from merged
mainrather than from the PR description —grep -con.forgejo/workflows/tests.ymlfor each flag. Landed via PR#732.