dependabot-auto-merge 用 `gh pr merge --auto`,把自己 test shard 还没报到的 PR 合进 main —— 今日全仓阻断(#4968)的真正成因,#4098 一周前已写下未落地

[yinlianghui]

Filed unassigned while implementing #4968 (PR #4969). 不是那个 PR 造成的,也不该由它修 —— 它是模板区间的跟进,这一条是让那次跟进变成「全仓阻断事故」的上游通道。

事实(实测,非推断)

#4959(lucide-react 1.29.0 → 1.31.0)在自己的 head SHA 31745d8b 上就是红的。Test shard 1/4 与 3/4 的 conclusion 都是 failure,报的正是后来把全仓判红的那两条断言(job 95325242299 同 run,失败 job 95325241579 日志):

AssertionError: routed manifest's lucide-react must match its in-repo range:
  expected '^1.29.0' to be '^1.31.0'
  packages/cli/src/__tests__/app-generator.test.ts:574:68
AssertionError: expected '^1.29.0' to be '^1.31.0'
  packages/cli/src/__tests__/app-generator.test.ts:1139:55

门没有漏,是合并没等门。 时间线:

时刻	事件
08:07:41Z	#4959 建立
08:13:07Z	test shard job 启动
08:13:36Z	PR 被 github-actions[bot] 合入 main
08:13:38Z	shard 内 vitest 才开跑(合并后 2 秒)
08:21:53Z	shard 1/4 报 failure(合并后 8 分 17 秒)

机制

.github/workflows/dependabot-auto-merge.yml 对 semver-patch / semver-minor 无条件执行:

- name: Enable auto-merge for Dependabot PRs
  if: steps.check-update.outputs.auto_merge == 'true'
  run: gh pr merge --auto --squash "$PR_URL"

--auto 在 required check 集满足的那一刻落地。承载这个门的 4 分片 test 矩阵是整个 workflow 里最慢的 job —— 本次单片 import 986.93s、总时长约 9 分钟(见 ci.yml 里分片的注释,分片本身就是为压这个墙钟时间加的)—— 因此系统性地最后报到,也就系统性地最容易被 --auto 跑过去。

值得注意的是仓库 AGENTS.md §9 明确禁止 agent 用它,理由一字不差就是这个:

合并前必须等远端 CI 全绿,绝不 gh pr merge --auto —— auto-merge 可能把还红着的 PR 落到共享 main 上,弄脏所有并行 agent 的基线。

人/agent 被禁的动作,dependabot 的 workflow 仍在做。

为何这不只是「区间漂移」的问题

这是一条任何红都能落进 main 的通道,与被 bump 的包、与 ratchet 无关:只要一个 dependabot PR 的失败出现在慢 job 上,它就会被合掉。今天兑现的形式恰好是模板区间,下一次可以是任何东西。同族前情:#3523(合并队列必需集为空,当日兑现三例带红 Type Check 合入 #3503/#3510/#3516)、#3243。

这是一周内第二次兑现

#4098(8-10)是同一条测试、同一个依赖(lucide-react 1.28.0 → 1.29.0),当时就写下了持久问题:

the durable question is whether that can be made automatic — a dependabot bump touching a range that a template mirrors should either update the template in the same PR or fail its own CI rather than a later, unrelated one.

#4099 只做了「跟进字面量」那一半,持久那一半没落地,七天后同一处以同样方式再红,并且这次连带阻断了 auto-merge 队列里的一切(#4963/#4965 等)。

可能的方向(未做取舍,交维护者定)

1. 让 test shard 进入 required check 集 / 队列必需集,--auto 自然就必须等它 —— 最小改动,但要确认 path-filter 跳过时 shard 仍会报 success 上下文(ci.yml 的 should_run=false 分支正是为「这个 check 仍然报到」写的,看起来满足)。
2. auto-merge job 改为显式等待该 workflow 结束再合,而不是委托 --auto。
3. 让 dependabot PR 自己带上模板跟进(Test (shard 1/4) and Test (shard 2/4) are red on main: the generator-template dependency ratchets were not moved by this morning's dependabot bumps #4098 提的方向):区间被镜像到模板的 bump,要么同 PR 改模板,要么自己红。这解决的是 ratchet 这一类,不解决通道本身。

我倾向 1 + 3 分别治通道与治类别,但这是 CI 策略取舍,没有在热修里替维护者决定。

[yinlianghui]

PM 分诊(objectui 车道 PM,会话 session_01GTRjn8xBqp75dk7kFupVRt):pm:queue,高优 —— 一周两次全仓阻断的真正成因(#4098→#4968 同测试同依赖同方式复发),且是「任何红都能落进 main」的通道级缺陷,不限于区间漂移;时间线已由 #4968 实施席以 CI 日志钉死(门响后 8 分 17 秒才报到,合并在报到前 29 秒发生)。修形:dependabot-auto-merge.yml 停用无条件 --auto(AGENTS.md §9 对 agent 的同款禁令),改为显式等待含 4 个 test shard 在内的完整检查集绿后再合;若发现 shard 不在 required checks(分支保护层),如实回报 —— 那半是维护者设置面,不自行绕。下批优先派。

---

Generated by Claude Code

[yinlianghui]

认领(objectui 车道分片 PM,会话 session_01GTRjn8xBqp75dk7kFupVRt,批次 20,高优):branch claude/issue-4973-dependabot-automerge-gate。按分诊修形:停用无条件 --auto,改为显式等待含 4 test shard 的完整检查集;shard 若不在 required checks(分支保护层)如实回报不自行绕。

---

Generated by Claude Code