fix(ci): prevent staging-ci tag failure and chained PR auto-close

[henrypark133]

Summary

• Fix update-tag shallow clone: Changed fetch-depth: 1 to fetch-depth: 0 in the update-tag job so the current_head SHA (captured by check-changes) is always available, even if staging receives new commits during the CI run. Previously failed with fatal: cannot update ref 'refs/tags/staging-tested': trying to write ref with nonexistent object.

• Only merge promotion PRs targeting main: The gate now checks the PR's base branch before merging. Chained PRs (targeting another promotion branch) are left open instead of merged. This prevents delete_branch_on_merge from auto-deleting the head branch and cascading closures of downstream chained PRs. When the bottom of the chain merges into main, GitHub auto-retargets the next chained PR.

Test plan

• Trigger staging CI manually and verify update-tag succeeds
• Verify chained PRs are NOT merged when gate passes (log shows "leaving open for chain resolution")
• Verify PRs targeting main ARE still merged when gate passes

🤖 Generated with Claude Code

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[Copilot]

Pull request overview

Adjusts the staging CI workflow to make the “tested” tag update resilient to new commits arriving during a run, and to prevent the gate from merging “chained” promotion PRs (which can cascade-close downstream PRs via automatic branch deletion).

Changes:

• Update the update-tag job checkout to fetch-depth: 0 so the previously-captured current_head commit object is always present when moving staging-tested.
• Gate merge logic now merges promotion PRs only when the PR base branch is main, leaving chained PRs open for GitHub’s retargeting behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[zmanian]

Found one blocking workflow issue here.

• .github/workflows/staging-ci.yml:421-447 now leaves chained promotion PRs open when they do not target main, but update-tag still force-advances staging-tested unconditionally once tests pass. If the upstream main-targeting promotion PR later fails or is closed, these commits have already been marked as processed and can be skipped permanently by later staging runs. staging-tested should only advance when the batch was actually merged, or it should track the merge result explicitly.

[henrypark133]

Thanks for the review! I looked into this carefully and I believe the current behavior is correct. Here's why:

The staging-tested tag and the PR diff are decoupled:

• staging-tested tag — only used in check-changes to decide whether to run the CI at all (tests + e2e). It prevents redundant test reruns.
• PR creation — controlled by ahead-check, which compares origin/main..origin/staging. This is completely independent of the tag.

So even if the tag advances and a chain later breaks (bottom PR closed), the commits aren't "skipped permanently":

1. Next CI run with new commits: has_changes = true (new commits since tag)
2. ahead-check still sees staging ahead of main (those unpromoted commits are still there)
3. A new promotion PR is created covering all unpromoted commits

The tag just says "we've already tested these commits." Re-running tests on the same code wouldn't help — if the gate failed due to a blocking review, that's tracked as a GitHub issue. Not advancing the tag would cause an infinite loop of re-testing the same commits every hour without new fixes.