fix(ci): stop grep no-match aborting the Linear attach step - #410
Merged
Merged
Conversation
GitHub runs `run:` blocks as `bash -e`. grep exits 1 when it matches nothing, which for this loop is the common case rather than an error -- most PRs carry no Linear reference. So the step died on the first PR without a ticket, immediately after printing the PR list and with no message of its own. Wrap each grep whose no-match is expected in `|| true`. Verified by running the loop under `bash -e` against the four PRs in v1.7.0.8rc1: it now completes and resolves ING-3400 from datahub-project#19466. The original was only ever exercised in an interactive shell, which does not set -e -- which is why it passed locally and failed in CI.
Audit of every command substitution in this workflow, prompted by the grep no-match failure: under `bash -e` any assignment whose final command exits non-zero kills the step, and several did so on paths that are normal operation rather than errors. - add-to-cli-next: `gh pr view` is the last command, so a 404 or an unreadable PR aborted before the `if steps.find-issue.outputs.issue != ''` guard could skip it. - linear-release: `git describe` exits 128 when no ancestor tag exists, making the `if [ -z "$PREV_TAG" ]` check immediately below unreachable dead code. - linear-release: `jq` exits 5 iterating null, which is what the cli-next membership query returns whenever the API errors. Guard each with `|| true` or jq's optional iterator, so the existing graceful-skip branches are actually reachable. Also give delete-linear-release the same error surfacing as the attach step. It was the last place where an auth or scope failure was indistinguishable from the release genuinely not existing -- which would let Linear drift out of sync with GitHub silently. Verified: every construct reproduced under `bash -e` before and after, and the range/resolution logic simulated end-to-end for both an RC and a stable. Note `run:` blocks here get `bash -e` WITHOUT pipefail, so only the last command in a pipeline determines the exit status.
sgomezvillamor
approved these changes
Aug 31, 2026
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.
Follow-up to #405. With the credential, permissions and query fixes in place, the attach step got all the way to resolving PRs and then died with no message:
Cause
GitHub runs
run:blocks asbash -e.grepexits 1 when it matches nothing — which in this loop is the common case, not an error: most PRs carry no Linear reference at all. So the step aborted on the first PR without a ticket, in a command substitution, producing no output of its own.Each grep whose no-match is expected is now wrapped in
|| true:Linear:comment scan(#NNNNN)extraction from the commit rangeVerification
Ran the loop under
bash -eagainst the four PRs inv1.7.0.8rc1. It completes and resolvesING-3400from datahub-project#19466 — one of four, which is the expected sparse coverage for OSS PRs.The original was only ever exercised in an interactive shell, which does not set
-e. That is precisely why it passed locally and failed in CI, and it is worth noting for anything else in this workflow that gets tested by hand.Checklist
actionlintandgithubActionsPrettierCheckpassbash -eagainst real PRs🤖 Generated with Claude Code