ci(a11y): fix findings count writing malformed GITHUB_OUTPUT on zero findings#3442
Conversation
…findings The accessibility check job fails on any PR where a changed src/gui file has zero findings — the check itself passes, but the step errors with "Unable to process file command 'output'... Invalid format '0'". Cause: `grep -c "^::warning"` prints `0` to stdout AND exits non-zero when there are no matches, so `COUNT=$(grep -c ... || echo "0")` captured BOTH grep's `0` and the `|| echo "0"`, producing the two-line value "0\n0". Writing `findings=0\n0` to $GITHUB_OUTPUT is malformed -> step failure. Fix: drop the duplicate echo; `|| true` swallows grep's exit code while keeping its own `0` output. Verified locally for both the zero-findings and N-findings cases. Seen on aethersdr#3441 (a clean GUI change with 0 a11y findings).
There was a problem hiding this comment.
Thanks @M7HNF-Ian — clean, minimal, and correct.
The diagnosis is right: grep -c prints 0 and exits non-zero on no-match, so || echo "0" was concatenating a second 0 and producing a multiline value for the findings output key, which GitHub Actions rejects. || true swallows the non-zero exit without appending — exactly the right shape.
Couple of small notes (non-blocking, just confirming the reasoning):
- The default GitHub Actions shell runs with
bash --noprofile --norc -eo pipefail, so without the||clauseset -ewould terminate the step on no-match. The replacement still satisfies that —|| truemakes the substitution exit 0 — so behavior underset -eis preserved. - The unrelated early-skip path at line 39 already writes
findings=0cleanly, so the fixedfindings=$COUNTpath now matches that contract.
Out of scope for this fix, but worth flagging in passing for a follow-up: the conditional on line 61 (steps.a11y.outputs.findings != '0') was also incidentally protected by this bug — when findings was malformed, the step couldn't set the output at all, which probably masked the empty-summary edge case. After this fix that gate works as designed, which is the right behavior anyway.
Looks good to me.
🤖 aethersdr-agent · cost: $8.6630 · model: claude-opus-4-7
…findings (aethersdr#3442) The accessibility check job fails on any PR where a changed `src/gui` file has **zero** findings — the check itself passes, but the step errors with: ``` ##[error]Unable to process file command 'output' successfully. ##[error]Invalid format '0' ``` ## Cause `grep -c "^::warning"` prints `0` to stdout **and** exits non-zero when there are no matches. So: ```bash COUNT=$(grep -c "^::warning" /tmp/a11y_output.txt || echo "0") ``` captures **both** grep's own `0` and the `|| echo "0"`, producing the two-line value `"0\n0"`. Writing `findings=0\n0` to `$GITHUB_OUTPUT` is malformed → step failure. ## Fix ```diff - COUNT=$(grep -c "^::warning" /tmp/a11y_output.txt || echo "0") + COUNT=$(grep -c "^::warning" /tmp/a11y_output.txt || true) ``` `grep -c` already prints `0` on no match; `|| true` simply swallows its non-zero exit under `set -e`, without appending a duplicate. Verified locally: | Input | Old `COUNT` | New `COUNT` | |---|---|---| | no `::warning` lines | `0\n0` (malformed) | `0` | | 2 `::warning` lines | `2` | `2` | Seen on aethersdr#3441 (a clean GUI change with 0 a11y findings).
The accessibility check job fails on any PR where a changed
src/guifile has zero findings — the check itself passes, but the step errors with:Cause
grep -c "^::warning"prints0to stdout and exits non-zero when there are no matches. So:COUNT=$(grep -c "^::warning" /tmp/a11y_output.txt || echo "0")captures both grep's own
0and the|| echo "0", producing the two-line value"0\n0". Writingfindings=0\n0to$GITHUB_OUTPUTis malformed → step failure.Fix
grep -calready prints0on no match;|| truesimply swallows its non-zero exit underset -e, without appending a duplicate. Verified locally:COUNTCOUNT::warninglines0\n0(malformed)0::warninglines22Seen on #3441 (a clean GUI change with 0 a11y findings).