fix(corpus): the workflow has never actually analysed anything - #7
Merged
Conversation
`find | head` was the last command in the fetch step. head closes the pipe once it has 50 lines, GNU find reports the write error and exits non-zero, and `set -euo pipefail` promotes that into a failed step. Every corpus job died there, before a single agentfile command ran, so the workflow has never actually analysed anything since it was added. Reproduced on ubuntu:24.04: the pipeline form exits 141, the file form exits 0. macOS hides it because BSD find swallows EPIPE, which is why this survived local testing. The list goes to a file and the count is printed, so the diagnostic also now says whether the sparse checkout brought anything at all.
…d off
The Analyse step opens with `set -uo pipefail` and then carefully records
each command's exit code, treating 1 as findings and anything higher as a
crash. None of that logic could ever run. GitHub invokes a `run:` block as
`bash -e {0}`, so -e is already on when the script starts, and `set -uo
pipefail` does not clear it: the step died on the first command that found
anything, before reaching the code that exists to allow exactly that.
expo/expo passed only because its configuration produces no findings, which
is why the bug looked repository-specific rather than total.
Verified on ubuntu:24.04 that `bash -e` plus `set -uo pipefail` still aborts
on a false, and that `set +e` restores the intended behaviour.
The summary step carried the same assumption and gets the same fix, because
a run that failed is precisely when its report needs to still be readable.
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
2 participants
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 scheduled corpus run has failed on every repository since it was added. Two
bugs, both in the shell rather than in agentfile, and the second was hidden
behind the first.
1. A diagnostic listing could fail the job
headcloses the pipe once it has 50 lines, GNU find reports the write errorand exits non-zero, and
set -euo pipefailpromotes that into a failed step.This was the last command in the fetch step, so the job died there, before a
single agentfile command ran.
Reproduced on
ubuntu:24.04: the pipeline form exits 141, the file form exits0. macOS hides it entirely because BSD find swallows EPIPE.
2. Findings are the expected outcome, and
-ewas killing themThe Analyse step opens with
set -uo pipefailand then carefully records eachcommand's exit code, treating 1 as findings and anything above that as a crash.
None of that logic could ever run. GitHub invokes a
run:block asbash -e {0}, so-eis already on when the script starts andset -uo pipefaildoes not clear it. The step died on the first command that foundanything, which is precisely the case the code below it exists to allow.
expo/expopassed only because its configuration produces no findings, whichmade the bug look repository-specific rather than total.
Verified on
ubuntu:24.04thatbash -eplusset -uo pipefailstill abortson a
false, and thatset +erestores the intended behaviour. The summarystep carried the same assumption and gets the same fix, because a run that
failed is exactly when its report needs to still be readable.
Verification
Dispatched against this branch: run 33389754989, all three green.
All five commands (
doctor,check,lint,audit,adopt) pluscontextnow run to completion on all three, within the exit-code contract.
No agentfile behaviour changes. Workflow only.