fix(lock-release): don't fail on PRs with merge conflicts

[hectahertz]

Closes #

The lock-release unlock workflow has been failing because the "Update all PRs" step uses xargs to call gh pr update-branch for each auto-merge PR. When any PR has merge conflicts, gh pr update-branch exits non-zero, xargs propagates exit code 123, and the whole job fails under bash's -e flag.

This means the unlock step was reported as failed even though the rulesets were toggled successfully. The only "failure" was that some PRs had conflicts and couldn't be updated, which is expected and shouldn't block the workflow.

Replaced xargs with a for loop that gracefully handles per-PR failures with || echo "Warning: ...".

Changelog

New

N/A

Changed

• lock-release unlock step no longer fails when some PRs have merge conflicts

Removed

N/A

Rollout strategy

• Patch release
• Minor release
• Major release; if selected, include a written rollout or migration plan
• None; CI workflow fix only, no package changes

Testing & Reviewing

This was diagnosed from the recent run logs. The rulesets toggle fine, but the PR update step fails:

✓ PR branch updated
✓ PR branch updated
X Cannot update PR branch due to conflicts
X Cannot update PR branch due to conflicts
✓ PR branch updated
##[error]Process completed with exit code 123.

Merge checklist

• Added/updated tests
• Added/updated documentation
• Added/updated previews (Storybook)
• Changes are SSR compatible
• Tested in Chrome
• Tested in Firefox
• Tested in Safari
• Tested in Edge
• (GitHub staff only) Integration tests pass at github/github-ui (Learn more about how to run integration tests)

[changeset-bot]

⚠️ No Changeset found

Latest commit: decd2bb

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Copilot]

Pull request overview

Adjusts the lock-release GitHub Actions workflow so the unlock job doesn’t fail just because some auto-merge PRs can’t be updated due to merge conflicts, avoiding false “failed” unlock runs when rulesets toggling succeeded.

Changes:

• Replaces the xargs-based gh pr update-branch invocation with a for loop.
• Converts per-PR update failures into warnings so the job can continue.

[Copilot]

gh pr update-branch ... || echo ... will now treat any update-branch failure as a success (not just merge-conflict failures). That can mask real problems like auth/permission issues or GitHub API outages and still report the workflow as successful. Consider detecting/ignoring only the known conflict case (or at least tracking failures and failing the step if all/most updates fail), while still continuing past individual conflict errors.

Suggested change

	for pr in $PR_NUMBERS; do
	gh pr update-branch -R primer/react "$pr" || echo "Warning: failed to update PR #$pr (likely has conflicts)"
	done
	failed=0
	for pr in $PR_NUMBERS; do
	if ! output=$(gh pr update-branch -R primer/react "$pr" 2>&1); then
	if echo "$output" | grep -qi "merge conflict"; then
	echo "Warning: failed to update PR #$pr (merge conflict detected)"
	else
	echo "Error: failed to update PR #$pr due to an unexpected error"
	echo "$output"
	failed=1
	fi
	fi
	done
	if [ "$failed" -ne 0 ]; then
	echo "One or more PR updates failed due to unexpected errors."
	exit 1
	fi

[hectahertz]

Sharing the diagnosis. The fix here silently swallows per-PR failures which isn't great either.

Root cause: The "Update all PRs" step uses xargs to call gh pr update-branch on each auto-merge PR. When any PR has merge conflicts (currently #7536 and #7532), the command exits non-zero, xargs propagates exit code 123, and bash's -e flag kills the job. The rulesets were actually toggled successfully in every run, it's just the PR update part blowing up.

Some options:

• continue-on-error: true on the step so the job passes but the step still shows its real status
• The for loop approach in this PR but with a tracked failure count that gets reported at the end
• Move the PR update to a separate job so the unlock job is always green

Leaving this for you to decide since you have more context on the intended behavior @llastflowers!