Cancel superseded CI validation
取消被取代的 CI 验证
Validation of an obsolete PR revision or master commit consumes runner capacity without establishing the newest revision’s status. Unconditional aggregate verdicts and coverage-history uploads can also keep cancelled runs doing bookkeeping. Preserving older post-merge runs favors historical completion over current validation, especially on the shared self-hosted pools.
English
Problem
Validation of an obsolete PR revision or master commit consumes runner capacity without establishing the newest revision’s status. Unconditional aggregate verdicts and coverage-history uploads can also keep cancelled runs doing bookkeeping. Preserving older post-merge runs favors historical completion over current validation, especially on the shared self-hosted pools.
Decision
Validation favors the newest run within each workflow/ref group. CI, CI master, real-API e2e, and the credential-free dsh and vendor pack validations use cancel-in-progress: true with ${{ github.workflow }}-${{ github.ref }}. Different PR refs and different workflows do not cancel each other. Event type is not part of the group: master pushes and manual benchmarks can supersede each other in CI master, and e2e pushes, scheduled runs, and manual runs can supersede each other on the same ref.
The reusable Python runtime builder uses ${{ !inputs.release }}. Its build-single-exe-${{ github.workflow }}-${{ github.ref }} group remains distinct from its caller’s group, and the caller workflow name isolates ordinary CI from release-owned builds. Release-owned builds are exempt because they belong to an intentional publication transaction. Publication, deployment, and metadata workflows retain their own policies; this decision does not apply cancellation indiscriminately across workflows.
The PR aggregate uses ${{ !cancelled() && github.event_name == 'pull_request' }}. The explicit status function preserves evaluation after failed or skipped dependencies rather than accepting GitHub’s default success-only condition. The aggregate still fails on any failure, cancellation, or skip among its dependencies when the workflow itself is not cancelled; cancellation of the whole workflow suppresses its obsolete verdict. Coverage duration history uses !cancelled() too: failed coverage can still save useful measurements, but cancelled coverage does not upload them. Wine’s always() cleanup remains necessary resource cleanup rather than optional bookkeeping.
This reverses the cancellation exemption in the failover runbook, master-only platform CI, and real-API e2e decision. Those notes retain independent value for pool trust and switching, platform coverage, and secret exposure. The release rehearsal decision retains runner selection and isolation ownership. None is fully superseded or archived.
Alternatives considered
Preserve running master-push drills. The former ${{ github.event_name != 'push' }} exemption favored periodic readiness evidence: each standby executes its complete unsharded aggregate with one gate worker and can outlast the interval between master merges. Even that policy did not guarantee every drill completed. GitHub retains one pending run per group, replacing intermediate pending pushes; cancellation is evaluated on the newly triggered run, so a manual benchmark sharing the master group could still cancel a drill. That rare manual interruption was accepted on the expectation of evidence from a subsequent push. The exemption’s cost was bounded by the master-only runtime checks, Wine, and two drills; PR jobs remained in a separate workflow, and exact-condition regression checks pinned the push-reachable job set. This policy is rejected in favor of freeing capacity for current validation, explicitly accepting standby starvation.
Protect a drill with job-level concurrency, or cancel only PR events. A job-level group cannot exempt a job from cancellation of its entire workflow. A PR-only cancellation condition also exempts manual dispatch: a repeated runner benchmark can occupy twelve larger runners for up to fifteen minutes rather than replacing an obsolete measurement. Workflow-level cancellation covers both pushes and manual runs.
Keep every post-merge, nightly, and pack run. Historical completion provides more per-commit and per-trigger evidence, but obsolete validation competes with the newest run. These validations do not publish packages, so preserving every run is not the same requirement as protecting an intentional publication transaction.
Replace every always() condition. Failure aggregation and resource cleanup have different obligations. A success-only aggregate can hide failed dependencies behind a skipped required check; removing unconditional Wine cleanup can leave resources running. Only cancelled-run bookkeeping is suppressed.
Consequences
Rapid master updates can repeatedly cancel the longer standby drills before they produce a verdict. Operators use the latest completed standby verdict, checking its age and commit before relying on it for failover readiness; a scheduled, running, or cancelled drill is not readiness evidence. The policy does not guarantee that every intermediate commit, nightly trigger, or benchmark completes. Different refs can still compete for shared host capacity.
Cancellation is a request handled by GitHub Actions and its runners, not a guarantee of immediate termination or bounded queue delay. Cleanup can still take time. The policy makes obsolete validation cancellable; it does not promise a fixed runtime or cancellation latency.
Verification
Workflow regressions pin workflow/ref isolation, release-owned exemptions, aggregate status conditions, coverage-history cancellation, and retained Wine cleanup. Platform routing regressions preserve the master/PR target split and release matrix; release rehearsal regressions preserve cancellation alongside runner eligibility and publication isolation. These configuration checks do not reproduce GitHub scheduling or runner shutdown. Live supersession and completed standby evidence remain CI verification responsibilities.
中文
问题
验证已被取代的 PR（Pull Request）修订或 master 提交会消耗运行器容量，却不能确定最新修订的状态。无条件执行的聚合判定和覆盖率耗时历史上传，还可能让已取消的运行继续处理记账任务。保留旧的合并后运行，意味着优先完成历史验证而非当前验证，在共享自托管池上尤其如此。
决策
验证优先保留各工作流/引用组内最新的运行。CI、CI master、真实 API e2e，以及无凭据的 dsh 和 vendor 打包验证，均在 ${{ github.workflow }}-${{ github.ref }} 组中使用 cancel-in-progress: true。不同 PR 引用和不同工作流不会相互取消。事件类型不参与分组：CI master 中的 master 推送与手动基准测试可以相互取代，e2e 的推送、定时运行和手动运行也可以在同一引用上相互取代。
可复用 Python 运行时构建器使用 ${{ !inputs.release }}。其 build-single-exe-${{ github.workflow }}-${{ github.ref }} 组与调用方的组保持区分，调用方工作流名称将普通 CI 与发布所属的构建隔离。发布所属的构建获得豁免，因为它们属于一次有意发起的发布事务。发布、部署和元数据工作流保留各自的策略；本决策不会不加区分地对所有工作流应用取消。
PR 聚合使用 ${{ !cancelled() && github.event_name == 'pull_request' }}。显式状态函数使其在依赖失败或跳过后仍然求值，而非采用 GitHub 默认的仅成功条件。当工作流本身未被取消时，聚合仍会因任意依赖失败、取消或跳过而失败；整个工作流被取消时则抑制其已失去用途的判定。覆盖率耗时历史也使用 !cancelled()：覆盖率失败时仍可保存有用的测量数据，但被取消的覆盖率运行不上传。Wine 的 always() 清理仍是必要的资源清理，而非可选记账任务。
本决策推翻故障切换手册、仅 master 执行的平台 CI 和真实 API e2e 决策中的取消豁免。这些记录对运行器池信任与切换、平台覆盖和密钥暴露仍有独立价值。发布演练决策仍负责运行器选择与隔离。没有记录被完全取代或归档。
曾考虑的替代方案
保留正在执行的 master 推送演练。 原有 ${{ github.event_name != 'push' }} 豁免优先保证周期性就绪证据：每条热备以单门禁工作进程执行完整的未分片聚合流程，耗时可能长于 master 合并间隔。即便该策略也不保证每次演练完成。GitHub 每个组仅保留一个待运行条目，会替换中间的待执行推送；取消条件针对新触发的运行求值，因此共享 master 组的手动基准测试仍可取消演练。当时接受了这种罕见的手动中断，期望后续推送提供证据。豁免成本被限定为仅 master 执行的运行时检查、Wine 和两条演练；PR 作业仍在独立工作流中，按精确条件匹配的回归检查固定推送可达作业集合。为释放容量给当前验证而否决该策略，明确接受热备因反复被取消而无法完成。
用作业级并发保护演练，或仅取消 PR 事件。 作业级分组不能让作业免于整个工作流的取消。仅针对 PR 的取消条件还会豁免手动触发：重复派发的运行器基准测试可能占用十二台大型运行器长达十五分钟，而非替换陈旧的测量。工作流级取消同时覆盖推送和手动运行。
保留每次合并后、每夜和打包运行。 完成历史运行能提供更多按提交和触发划分的证据，但已被取代的验证会与最新运行竞争。这些验证不发布包，因此保留每次运行与保护有意发起的发布事务并不是同一项要求。
替换每个 always() 条件。 失败聚合与资源清理承担不同义务。仅成功时执行的聚合可能把依赖失败隐藏为跳过的必需检查；移除无条件 Wine 清理则可能留下仍在运行的资源。只有已取消运行的记账任务被抑制。
后果
master 快速更新可能反复取消耗时更长的热备演练，使其无法产出结论。运维人员使用最近一次已完成的热备结论，并在依赖它判断故障切换就绪状态前核对其时间和提交；已调度、正在执行或已取消的演练都不构成就绪证据。该策略不保证每个中间提交、每夜触发或基准测试都能完成。不同引用仍会竞争共享主机容量。
取消是由 GitHub Actions 及其运行器处理的请求，不保证立即终止或限定排队时长。清理仍可能耗时。该策略让已被取代的验证可以被取消，但不承诺固定运行时长或取消延迟。
验证
工作流回归测试固定工作流/引用隔离、发布所属构建豁免、聚合状态条件、覆盖率历史取消及保留的 Wine 清理。平台路由回归测试保留 master/PR 目标划分与发布矩阵；发布演练回归测试在验证取消策略的同时保留运行器准入与发布隔离。这些配置检查不重现 GitHub 调度或运行器停止过程。真实运行取代行为与已完成热备证据仍由 CI 负责验证。