fix(ci): piping into grep -q is broken under pipefail#44
Merged
Conversation
The aarch64 release build failed its own verification with dpkg-deb: error: tar subprocess was killed by signal (Broken pipe) ::error::.deb does not ship /usr/bin/thinkutils The file was there. grep -q exits the instant it matches, dpkg-deb takes SIGPIPE while writing the rest of the listing, and pipefail propagates that non-zero status -- so FINDING the file is what made the check report it missing. Failing in that direction is the dangerous one: the same race resolving the other way passes a package nobody verified. Timing-dependent, not architecture-specific. x86_64 passed on the same commit; ARM lost the race. It has been latent in release.yml since before this session and would eventually have failed an x86_64 release too. Verified which formulations actually survive, because the obvious fix does not -- capturing the output first and piping THAT into grep -q fails identically, since printf takes the SIGPIPE instead: producer | grep -q PATTERN MISSING (bug) capture, then pipe into grep -q MISSING (bug) grep -q PATTERN <<<"$contents" found producer | grep PATTERN >/dev/null found (no -q, so grep reads to EOF) Uses the herestring form, and lists the .deb once into a variable rather than twice. Applied to the same shape in publish-copr.yml (copr-cli list) and the two in the launch test, where a false negative would have failed a release for no reason.
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
thinkutils | 6cf5f81 | Jul 20 2026, 06:02 AM |
…iled Two problems, both found by dry-running the workflows before using them. Neither workflow checked out the tag it was asked to publish. checkout had no ref, so it took the default branch and then labelled the result with the requested version. Publishing main's spec, PKGBUILD and manifests under an older tag's version number is wrong on its own; it surfaced here as COPR fetching a v0.2.0 tarball during a run explicitly asked to publish 0.1.10, because main had already been bumped. The tag check used the 'origin' alias, which depends on the checkout's local git config being readable. Inside a container it is not, so: fatal: 'origin' does not appear to be a git repository ::error::v0.1.10 does not exist on origin - push it before publishing The tag existed. The step reported the wrong cause entirely, and would have sent someone looking for a missing tag rather than a git config problem. Fedora's container tolerated it and Arch's did not, so this would have looked arch-specific too. Both now resolve the tag against an explicit repository URL, which needs no local config, and check out that tag.
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
1 participant
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
v0.2.0release failed.build (aarch64)failed its own verification,releasewas skipped, nothing published — the gating held, but the check was wrong.The file was there.
grep -qexits the instant it matches,dpkg-debtakes SIGPIPE writing the rest of the listing, andpipefailpropagates that non-zero status — so finding the file is what made the check report it missing.Why this matters more than a red run
release.ymlsince before this session; it would have failed an x86_64 release eventually.The obvious fix does not work
Capturing the output first and piping that into
grep -qfails identically —printftakes the SIGPIPE instead. I found that by testing every formulation rather than reasoning about it:producer | grep -q Pgrep -qgrep -q P <<<"$contents"producer | grep P >/dev/null-q, so grep reads to EOF)Uses the herestring form, and lists the
.debonce into a variable instead of twice.Same shape elsewhere
publish-copr.yml—copr-cli list | grep -qE(external command, same exposure)test-gui-packages-docker.sh×2 — small strings so it works in practice, but a false negative there fails a release for no reasonNo pipes into
grep -qremain in any workflow or script.134 tests pass. After this merges,
v0.2.0gets re-tagged and re-released.