Repository navigation
fix(homebrew): make-tarball's self-check reported the CLI missing under pipefail (EPIPE) — main's first tap publish - #2774
Conversation
…rep -q — EPIPE under pipefail reported the CLI missing on main's first tap publish The publish job on main (run 33313367517) failed at Tarball with 'tar: stdout: write error' and 'tarball … does not contain deploy/homebrew/bin/memex-local' — the archive carried it; grep -q had closed the pipe on the first match. The listing goes to a variable first, exactly the fix the workflow's own steps already got.
There was a problem hiding this comment.
Pull request overview
Fixes make-tarball.sh’s tarball self-check so it doesn’t falsely report the CLI missing when pipefail is enabled and grep -q closes the pipe early (EPIPE), which previously broke the first “publish tap from main” attempt.
Changes:
- Avoids the
tar | grep -qEPIPE/pipefail trap by capturingtar -tzfoutput before checking for the CLI entry.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…dots are not wildcards)
The shard-5 red is not attributable to this diffThis PR changes exactly one file — Measured rather than assumed: across the last 6 main runs ( What it is, and why it will recurIt is a liveness/ordering test with real time in it, and it is inherently contention-shaped: ctx.Log("step one");
return ObserveMessage(ctx.ActivityPath, "step one").Timeout(30.Seconds())
.SelectMany(_ => { ctx.Log("step two");
return ObserveMessage(ctx.ActivityPath, "step two").Timeout(30.Seconds()); })It asserts a second progress line lands after the first was observed, through the real activity channel, bounded by two 30 s timeouts nested inside a 60 s one. Under a loaded shard the observation can miss its window — and when it does, the failure looks identical whether the channel genuinely closed early or the shard was merely busy. Two things worth separating, since the outcome is the same red:
I am not re-running it to see whether it goes away — that discriminates nothing, and the attribution above is already stronger than a second sample would be. Nothing in this PR needs changing on account of it; if it recurs on other unrelated diffs it deserves its own issue, and the fix is to make it wait on the ordering signal rather than on wall clock. |
The
Publish the tap (main)job of run 33313367517 (the merge of #2766) failed at Tarball:The archive carried the file.
tar -tzf … | grep -qxis the same EPIPE trap the workflow's own steps were cured of on the PR: grep -q closes the pipe on its first match, tar dies writing the rest, and underpipefailthe self-check reads as a missing CLI. The listing now goes to a variable first. Verified locally underbash -o pipefailand shellcheck-clean; the macOS job re-exercises the script on this PR.🤖 Generated with Claude Code
https://claude.ai/code/session_01C1SquDKJNKZxEUbuaPjUgu