This is a correct, targeted fix for a real pipefail hazard.
The root cause is well understood: git show … | grep -q causes grep -q to exit as soon as it finds its first match, which sends a SIGPIPE (exit 141) to git show mid-stream. With set -euo pipefail in effect, bash sees a non-zero exit from a pipeline member and fails the whole command — even though the version was found. The script was reporting a missing changelog entry when the version was actually present.
The fix breaks the pipeline by capturing git show's output into REMOTE_CHANGELOG first (|| true absorbs any real git show failure gracefully, which is fine because the subsequent grep will then find nothing and the script will exit with a useful error), then feeds the variable into grep via a here-string. A here-string is entirely in-process, so grep -q exiting early has nothing to SIGPIPE. The logic is correct and the comment explaining why is clear and accurate.
One small observation: grep … <<< "$REMOTE_CHANGELOG" is a bashism, but the shebang is already #!/usr/bin/env bash and the rest of the script uses bash-specific constructs ([[ ]], $BASH_SOURCE, etc.), so there's no portability regression here.
The symmetrical path for a plain git checkout (line 144) uses grep -q … "$CHANGELOG" on a real file — no pipe involved — so it never had this problem and doesn't need changing.
Ready to merge.
Verdict: ready
{
"owner": "mirendev",
"repo": "runtime",
"number": 976,
"verdict": "ready",
"event": "approve",
"summary": "This is a correct, targeted fix for a real `pipefail` hazard.\n\nThe root cause is well understood: `git show … | grep -q` causes `grep -q` to exit as soon as it finds its first match, which sends a SIGPIPE (exit 141) to `git show` mid-stream. With `set -euo pipefail` in effect, bash sees a non-zero exit from a pipeline member and fails the whole command — even though the version *was* found. The script was reporting a missing changelog entry when the version was actually present.\n\nThe fix breaks the pipeline by capturing `git show`'s output into `REMOTE_CHANGELOG` first (`|| true` absorbs any real `git show` failure gracefully, which is fine because the subsequent `grep` will then find nothing and the script will exit with a useful error), then feeds the variable into `grep` via a here-string. A here-string is entirely in-process, so `grep -q` exiting early has nothing to SIGPIPE. The logic is correct and the comment explaining *why* is clear and accurate.\n\nOne small observation: `grep … \u003c\u003c\u003c \"$REMOTE_CHANGELOG\"` is a bashism, but the shebang is already `#!/usr/bin/env bash` and the rest of the script uses bash-specific constructs (`[[ ]]`, `$BASH_SOURCE`, etc.), so there's no portability regression here.\n\nThe symmetrical path for a plain git checkout (line 144) uses `grep -q … \"$CHANGELOG\"` on a real file — no pipe involved — so it never had this problem and doesn't need changing.\n\nReady to merge.",
"posted_to_pr": true
}