Fix SIGPIPE false negative in Backport Release workflow validation

[Kosinkadink]

The "Validate source branch is cut directly from the latest stable release" step in the Backport Release workflow fails with a spurious not found error even when the source branch is correctly cut from the latest stable tag. This blocked the first attempted run: https://github.com/Comfy-Org/ComfyUI/actions/runs/26257815677

Root cause

The check uses:

�ash set -euo pipefail ... if ! git rev-list --first-parent "${source_sha}" \ | grep -qx "${LATEST_TAG_SHA}"; then

On a real ComfyUI branch git rev-list --first-parent streams ~10k SHAs (~400 KB) — well beyond the 64 KB pipe buffer. grep -q finds the match on roughly line 4 and exits immediately, closing the read end of the pipe. git rev-list then receives SIGPIPE on its next write and exits 141. With pipefail, the pipeline's exit code becomes 141 (the leftmost non-zero), so if ! interprets the result as "no match" and emits the error — even though the SHA was actually found.

Fix

Capture the first-parent rev-list output into a variable, then grep against a here-string:

�ash first_parent_chain="$(git rev-list --first-parent "${source_sha}")" if ! grep -Fxq "${LATEST_TAG_SHA}" <<< "${first_parent_chain}"; then ... fi

Why this form:

• No live pipe between producer and consumer. git rev-list runs to completion (its output is buffered into the shell variable) before grep ever sees the data, so SIGPIPE cannot occur regardless of pipefail.
• Preserves the original semantics exactly — it still asserts that LATEST_TAG_SHA is on the first-parent chain of the source branch, not merely a DAG-ancestor. (An earlier revision of this PR used git merge-base --is-ancestor, but that only checks DAG ancestry and would accept the edge case where LATEST_TAG_SHA is the second parent of a merge commit on the branch.)

The follow-up all_added vs first_parent_added check is unchanged. Both of its rev-list | sort pipelines are already SIGPIPE-safe because sort drains stdin to EOF.

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR updates the backport release workflow’s ancestry validation to capture git rev-list --first-parent "${source_sha}" into a variable (first_parent_chain) and then test whether LATEST_TAG_SHA appears using grep -Fxq with a here-string. Surrounding comments were updated to document the prior pipeline’s SIGPIPE/set -o pipefail hazard.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: fixing a SIGPIPE issue in the Backport Release workflow validation.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description check	✅ Passed	The PR description clearly explains the SIGPIPE bug in the pipeline and the fix using a variable capture with a here-string.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

Warning

Review ran into problems

🔥 Problems

Git: Failed to clone repository. Please run the @coderabbitai full review command to re-trigger a full review. If the issue persists, set path_filters to include or exclude specific files.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/backport_release.yaml:
- Around line 122-126: The current check uses git merge-base --is-ancestor which
only enforces DAG ancestry and can wrongly allow cases where ${LATEST_TAG_SHA}
is a non-first-parent ancestor; replace that check with an explicit first-parent
containment test by checking membership of ${LATEST_TAG_SHA} in the first-parent
history of ${source_sha} (e.g., run git rev-list --first-parent "${source_sha}"
and test that ${LATEST_TAG_SHA} appears), and use a SIGPIPE-safe test (grep -F
-x -q or equivalent) so the workflow truly enforces "tag is on the first-parent
chain" before proceeding.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 6623bd1b-2320-47e8-8f0a-7fd340f57077

📥 Commits

Reviewing files that changed from the base of the PR and between 32e5839 and 54ee580.

📒 Files selected for processing (1)

• .github/workflows/backport_release.yaml

[coderabbitai]

♻️ Duplicate comments (1)

.github/workflows/backport_release.yaml (1)

113-119: ⚠️ Potential issue | 🟡 Minor | ⚖️ Poor tradeoff

Misleading comment: the checks do not fully enforce first-parent containment.

The comment claims the two checks together enforce "tag is on the first-parent chain", but git merge-base --is-ancestor only checks DAG ancestry, not first-parent membership specifically. There exist edge cases where both checks pass despite the tag being a non-first-parent ancestor (e.g., the tag is the second parent of a commit on the first-parent chain, and the commits added afterward form a linear chain).

The past review comment on lines 122-126 correctly identified this issue and provided a SIGPIPE-safe alternative that maintains the first-parent guarantee by explicitly checking membership via grep on the captured first-parent history.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/backport_release.yaml around lines 113 - 119, The comment
is incorrect: git merge-base --is-ancestor only checks DAG ancestry, not
first-parent chain membership. Replace the current git merge-base --is-ancestor
check (which compares "${LATEST_TAG_SHA}" and "${source_sha}") with a
first-parent membership test that enumerates the first-parent history of
"${source_sha}" (using git rev-list --first-parent) and then verifies
"${LATEST_TAG_SHA}" appears in that list (use a SIGPIPE-safe check such as
capturing the rev-list output into a variable and testing it with grep -Fxq or
grep via a here-string) so the workflow truly enforces "tag is on the
first-parent chain."

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Duplicate comments:
In @.github/workflows/backport_release.yaml:
- Around line 113-119: The comment is incorrect: git merge-base --is-ancestor
only checks DAG ancestry, not first-parent chain membership. Replace the current
git merge-base --is-ancestor check (which compares "${LATEST_TAG_SHA}" and
"${source_sha}") with a first-parent membership test that enumerates the
first-parent history of "${source_sha}" (using git rev-list --first-parent) and
then verifies "${LATEST_TAG_SHA}" appears in that list (use a SIGPIPE-safe check
such as capturing the rev-list output into a variable and testing it with grep
-Fxq or grep via a here-string) so the workflow truly enforces "tag is on the
first-parent chain."

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: bbf21dd2-1982-4ddb-8376-60f9ba5a8480

📥 Commits

Reviewing files that changed from the base of the PR and between 54ee580 and 5e1a3f8.

📒 Files selected for processing (1)

• .github/workflows/backport_release.yaml