fix(land-and-deploy): detect merged PR after gh failure#1620
Open
davidfoy wants to merge 1 commit into
Open
Conversation
After ANY non-zero exit from `gh pr merge`, query authoritative GitHub PR state before retrying or stopping. Replaces the narrow worktree-specific trigger with a universal post-failure invariant. Three outcome branches: - MERGED: success path. Capture SHA, offer (non-force) cleanup of clearly-stale worktrees with no uncommitted work, continue to CI detection. - OPEN + auto-merge enabled: queue-wait path (existing merge-queue handling). - OPEN (no auto-merge) or CLOSED: genuine failure, surface both errors, STOP. Hard rule: never call `gh pr merge` twice after a failure. Server state is authoritative. Worktree cleanup is non-destructive — candidates-only, no --force, defers to user. Related: cli/cli#3442, cli/cli#13380.
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
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.
Problem
gh pr merge --squash --delete-branch(and--autovariants) can exit non-zero with a local git error — most commonly a worktree conflict likefatal: 'main' is already checked out at '/path'— while the server-side merge has already succeeded. The/land-and-deployskill had no detection for this case: a naive retry ofgh pr mergewould be a destructive second attempt against a now-merged PR.This isn't a worktree-only issue. Any non-zero exit from
gh pr mergecan mask a successful server-side merge if the API call completed before the local cleanup phase failed. Tracked upstream in cli/cli#3442 and cli/cli#13380.Symptom in the field: the operator sees a "deploy failed" message, manually investigates, and discovers the PR merged but the deploy never fired — leaving prod on stale code with no automation.
Fix
Replace the previous (worktree-specific) recovery with a universal post-failure invariant: after ANY non-zero
gh pr mergeexit, query authoritative PR state before retrying or stopping. Three branches:MERGED→ success path. Capture merge SHA, offer (don't force) cleanup of clearly-stale worktrees with no uncommitted work, continue to existing §4a CI detection.OPEN+ auto-merge enabled → queue-wait path (proceeds to existing merge-queue handling).OPEN(no auto-merge) orCLOSED→ genuine failure. Surface both errors, STOP.Hard rule: never call
gh pr mergetwice after a failure. Server state is authoritative.Worktree cleanup is non-destructive — lists candidates, requires no uncommitted work, defers to user rather than
--forceing.Files
land-and-deploy/SKILL.md— adds§4a-postfailsection between the permission-error STOP and the existing§4amerge-queue detection.Related
gh pr merge -dwith git worktrees cli/cli#3442