From 0573220600ad4be163af62a73b0aa72f56dd9857 Mon Sep 17 00:00:00 2001 From: Lily Shen <115414357+lilyshen0722@users.noreply.github.com> Date: Tue, 25 Aug 2026 18:43:14 -0700 Subject: [PATCH] ci: run the merge-to-main guards when a PR is retargeted Both guards are scoped to base=main on purpose -- tests.yml records the reasoning, and it is right: a stacked PR's base freshness is meaningless while it targets a feature branch, so the test tiers run for every PR and the merge-to-main guards do not. The gap is the transition. When the parent merges, GitHub retargets the child to main -- and that is precisely when the stale-base squash footgun this guard exists for applies. Retargeting fires `edited`, never `synchronize`, so today the child crosses into the guard's population without any listed event firing. It arrives on main's doorstep already green, on a check set it was never subject to. Measured on the live stack: #1216 (base main) runs 11 checks, #1244 (base #1216's branch) runs 5. Both read CLEAN. When #1216 merges, #1244 inherits main as its base and still shows 5. Adds `edited` to both. Cost is a re-run on title/body edits: one fetch and a merge-base. Co-Authored-By: Claude Opus 5 --- .github/workflows/package-version-guard.yml | 6 +++++- .github/workflows/pr-base-freshness.yml | 11 ++++++++++- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/.github/workflows/package-version-guard.yml b/.github/workflows/package-version-guard.yml index 9c493ec886..78a35b64f0 100644 --- a/.github/workflows/package-version-guard.yml +++ b/.github/workflows/package-version-guard.yml @@ -17,7 +17,11 @@ name: Package Version Guard on: pull_request: branches: [ main ] - types: [opened, synchronize, reopened, ready_for_review] + # `edited` catches base-branch retargeting — see the note in + # pr-base-freshness.yml. A stacked PR retargeted to main after its parent + # merges enters this guard's population without any event in the list + # below ever firing for it. + types: [opened, synchronize, reopened, ready_for_review, edited] permissions: contents: read diff --git a/.github/workflows/pr-base-freshness.yml b/.github/workflows/pr-base-freshness.yml index 655f8136ee..3273fa6f86 100644 --- a/.github/workflows/pr-base-freshness.yml +++ b/.github/workflows/pr-base-freshness.yml @@ -20,7 +20,16 @@ name: PR Base Freshness on: pull_request: branches: [ main ] - types: [opened, synchronize, reopened] + # `edited` is load-bearing, not tidiness. This guard is deliberately + # scoped to base=main (see tests.yml) — a stacked PR's base freshness is + # meaningless while it targets a feature branch. But when its parent + # merges, GitHub RETARGETS the child to main, and that is the exact moment + # the stale-base footgun applies. Retargeting fires `edited`, never + # `synchronize`, so without this the child crosses into the guard's + # population and is never inspected: it arrives already-passing on a check + # set it was never subject to. Cost is a re-run on title/body edits too — + # one fetch and a merge-base, seconds. + types: [opened, synchronize, reopened, edited] permissions: contents: read