3.2 KiB
Agent Note: 可移植的拉取请求必需 CI
Status: implemented
English | 中文
问题
分配到组织自有运行器标签的拉取请求必需作业，在 GitHub 无法为这些池分配运行器时会持续排队。工作流本身有效，GitHub 标准托管作业仍能通过，但 all checks passed 始终无法启动，原本健康的拉取请求因此无法满足分支保护要求。
账单状态正常、运行器定义处于 Ready 状态以及较高的自动扩缩容上限，都不能证明指定的运行器池可以接收作业。必需的正确性检查需要一条可移植的执行路径，且该路径不能依赖仓库外部的运行器预配。
决策
CI 在 GitHub 标准的 ubuntu-latest 或 windows-2025 容量上运行每项拉取请求必需作业。主 Node 作业和 Windows 作业保留各自完整的合并清单，而顶层门禁、覆盖率、ESLint、publint 和快照回放在这些较小的主机上均使用 1 个工作线程。Node 版本通过 actions/setup-node 选择；Windows 作业会在安装采用符号链接的工作区前启用开发人员模式。
node 24 / complete、Node 兼容性、Python SDK 和 windows node 24 / complete 作业继续作为 all checks passed 的依赖项；为恢复可用性，不会移除任何门禁，也不会将其降为观测性检查。分支保护继续要求 e2e 和 all checks passed。
两项手动大型运行器套件和全部 12 个组织自有标签继续用于测量，但不参与普通拉取请求。大型运行器测量结果继续作为后续性能工作的证据，跨平台串行参考流程则继续作为 master 推送时独立的完整性检查。
曾考虑的替代方案
等待组织运行器恢复分配。 未分配运行器的队列不会产生仓库诊断信息，而且可能无限期阻塞每个拉取请求，因此依赖外部恢复不能构成正确性路径。
仅使用最小的组织自有运行器池。 每个指定的运行器池都需要经过相同的组织分配边界；减少核心数不能消除导致作业排队的依赖。
在容量不可用时跳过检查或降低其级别。 这种方式通过丢弃证据而非执行仓库的必需契约来使状态变绿。
在标准运行器上保留大型主机的工作线程上限。 完整仓库门禁及其内层工作线程池并发运行时，可能超出较小主机的内存和 CPU 配额，使可用性修复变成资源争用故障。
后果
普通拉取请求无需组织专有配置即可获得运行器，一次实际的分支头精确运行能够证明分支保护使用的同一组命令。代价是，与实测的大型运行器拓扑相比，总耗时更长，而且按整分钟计费的标准运行器用量更多。
手动大型运行器基准测试可以继续排队，而不会阻塞拉取请求。要将大型运行器恢复为必需路径，需要在分支头精确作业获得非零运行器 ID 并可靠完成后，另行作出基于证据的决策；仅改变运行器定义的状态还不够。