高频状态分支如何避免 CI 通知风暴

一个定时自动化把恢复状态保存在 Git 中。长任务运行期间，它会向专用分支提交租约心跳、检查点和回读结果。这些写入有明确用途：进程中断后，接手者可以重建所有权并安全恢复。

仓库的持续集成工作流却把每次状态写入都当成代码变化。打开 Pull Request 后，同一提交可能同时触发分支 push 和 pull_request 两条运行。测试夹具出现真实错误时，状态分支持续前进，相同失败便被反复通知。一个缺陷最终看起来像几十起新事故。

稳定处理方式是让 CI 跟随审查边界。状态提交继续保留审计能力；完整验证只在代码进入审查，以及审查结果进入默认分支时执行。

先把通知、运行和提交对齐

修改工作流前，先按时间关联通知、Actions 运行、提交和 Pull Request 状态。脱敏后的历史呈现出下面的模式：

证据	观察结果
状态分支	心跳与检查点持续生成合理提交
工作流触发器	push 和 pull_request 同时覆盖这段分支历史
Draft 状态	多数分支推送也会同步 Pull Request
失败特征	多次运行在相同测试夹具、相同断言边界失败
通知数量	40 次推送生成 40 条 push 运行和 39 条 PR 运行

这些失败包含真实问题。最早一项来自临时 Git 目录的清理竞争；后续失败来自历史测试夹具错误绑定到尚未生效的新策略。触发器又把相同失败复制到连续的运行状态提交上，告警数量因此失去故障数量的含义。

只关闭通知会遮住回归，只修测试也会保留下一次通知风暴的结构。断言错误与事件模型都需要处理。

先区分三类提交

同一分支承载了三类变化：

1. 运行状态：租约心跳、检查点与恢复证据。
2. 可审查实现：控制器、测试、工作流或文档变化。
3. 集成结果：合入默认分支的精确版本。

三类变化可以使用不同的验证频率。运行状态需要廉价的结构门禁和确定性写入器。可审查实现需要在允许合并前跑完整测试。集成结果需要在精确默认分支提交上完成一次回归。

GitHub Actions 会独立响应 push 和 pull_request 事件；Pull Request 还能用 types 限定到 ready_for_review 等活动（工作流触发事件）。工作流应直接表达这些边界。

把完整 CI 放到审查边界

可以把通用工作流写成下面的形状：

name: Repository checks

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
    types:
      - opened
      - reopened
      - synchronize
      - ready_for_review
  workflow_dispatch:

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

jobs:
  validate:
    # Draft condition here.
    runs-on: ubuntu-latest
    steps:
      - uses: >-
          actions/checkout@v7
      - run: >-
          python -m unittest
          discover -s tests
          -p 'test_*.py' -v

每一段承担独立职责：

• push 只监听 main，状态分支的检查点不会再启动第二条完整运行。
• Draft Pull Request 仍生成可见检查，验证 job 处于 skipped。
• ready_for_review 在变更开始具备可合并资格时执行完整测试。
• 非 Draft Pull Request 后续更新 head 时再次运行完整测试。
• 合并提交在 main 上执行一次完整回归。

这里存在一个容易忽略的必需检查边界。GitHub 文档说明，若整个必需 workflow 因路径过滤、分支过滤或跳过消息而不运行，对应检查可能长期保持 Pending 并阻塞合并。job 内部通过 if 跳过时，会向合并门禁报告成功结论（排查必需状态检查）。因此，Draft 条件应放在 job 层，让必需 workflow 仍然存在。

收敛已经过时的运行

高频分支可能在上一轮验证尚未结束时再次提交。只有最新 head 可以合并，继续测试旧 head 的价值通常很低。

按 Pull Request 编号或 ref 建立并发组，可以让同一审查链路共享一个身份。设置 cancel-in-progress: true 后，新运行会替换仍在执行的旧运行。GitHub 的并发契约默认让一个组最多保留一个执行中成员和一个等待成员；取消选项还会终止旧的执行中成员（工作流并发控制）。

并发组名称需要包含足以隔离工作流的上下文。多个无关工作流若共用过宽的固定名称，可能相互取消。

在写入器附近保留廉价门禁

减少托管 CI 次数并不代表状态分支可以任意写入。每次提交前，自动化仍应执行确定性检查：

• 校验状态结构和允许的迁移；
• 确认租约所有者与预期远端 head；
• 限定为获准的状态路径；
• 仅做普通快进推送；
• 保证重试幂等；
• 保留足以重建运行过程的证据。

本次处理还把属于同一状态迁移的检查点与租约刷新合并成一次快进提交。租约仍然新鲜时，提前心跳直接返回零写入成功。这些改动减少了分支产生变化的源头，也保留了恢复契约。

只调整工作流可以减少 runner 消耗，却无法消除多余的状态迁移。写入器和 CI 需要一起收敛。

在真实边界完成验证

新路径分四层验证：

1. 工作流结构测试检查默认分支 push、Draft 条件、Pull Request 活动类型、并发键和测试自动发现。
2. 控制器测试覆盖租约、检查点、恢复与历史策略快照。
3. Draft Pull Request 生成 skipped job，不执行完整测试。
4. 转为 Ready 的精确 head 通过一次完整 PR 验证；合并提交再通过一次默认分支回归。

最终证据同时绑定送审 head 与合并提交。某个早期检查点通过测试，无法证明后来进入 main 的版本。

适用边界

该设计适合把 Draft 定义为“运行状态仍在组装”，把 Ready 定义为“开始执行完整合并门禁”的仓库。如果团队要求每次 Draft 提交都可独立发布，就应保留完整的 Pull Request 运行。

若每个中间版本都会生成必须保存的产物或迁移结果，也不宜取消旧运行。此时可以排队执行，或为不同产物分配独立并发身份。

可复用的结论是先为写入分类，再分配 CI。频繁运行状态可以继续进入 Git，但无需继承可审查代码的全部验证成本和告警含义。写入器负责廉价不变量，完整测试落在明确审查边界，最后核对真正进入默认分支的精确提交。