4.1 KiB
Agent Note: 拉取请求 CI 的可移植恢复边界
Status: implemented
English | 中文
问题
分配到组织自有运行器标签的拉取请求必需作业，在 GitHub 无法为这些池分配运行器时会持续排队。工作流本身有效，GitHub 标准托管作业仍能通过，但 all checks passed 始终无法启动，原本健康的拉取请求因此无法满足分支保护要求。
账单状态正常、运行器定义处于 Ready 状态以及较高的自动扩缩容上限，都不能证明指定的运行器池可以接收作业。必需的正确性检查需要预先明确一条可移植恢复路径，即使日常低延迟路径依赖仓库外部的运行器预配也不例外。
决策
CI 在仅限本仓库使用的企业级 32 核运行器池上运行必需的主 Node 24 作业，以及稳定的 all checks passed 聚合流程。该聚合流程不执行代码检出或仓库门禁；但让它与所依赖的实质性作业共用企业级运行器池，可以避免这些作业已经成功后，必需判定结果又引入一项单独的标准托管计费依赖。必需的 Windows 作业在标准 ubuntu-latest 上通过 Wine 运行 Windows Node 以覆盖阻断性检查范围（Wine 通道决策），使拉取请求的 Windows 契约不依赖任何 Windows 运行器分配；完整的原生内核 Windows 清单位于 master 串行参考流程中。标准 ubuntu-latest 作业保留 Node 22.19、Node 26 和 Python SDK 兼容性，master 则运行完整的 Linux、macOS 和 Windows 串行参考流程。这些标准托管作业让可移植执行边界保持可观测，而不必在每个拉取请求中重复主清单。
两项 Linux 主作业、Node 兼容性、Python SDK 和 windows node 24 / wine blocking 继续作为 all checks passed 的依赖项；分支保护继续要求 e2e 和 all checks passed。剩余的企业级 Linux 运行器标签无法分配运行器时没有自动后备机制：标准作业会继续报告各自的契约，但无法产出缺失的必需结果。
当前主拓扑及其测量结果由大型运行器决策记录。跨平台串行参考流程继续作为独立的标准托管完整性检查，手动大型运行器套件则保留规格比较，同时不扩大普通必需矩阵。
曾考虑的替代方案
将 Linux 主作业和聚合流程保留在标准容量上。 此方案消除了剩余的企业级运行器分配依赖，但标准运行器上的完整作业反馈明显更慢，仍会遇到共享容量排队。当前拆分既保留可移植兼容性和串行证据，又将企业级运行器容量用于 Linux 主关键路径。
根据标称核心数选择企业规格。 基准测试表明扩展效果不呈单调变化，设置耗时也存在波动，因此必需运行器池改由完整作业的精确测量结果选定。
在容量不可用时跳过检查或降低其级别。 这种方式通过丢弃证据而非执行仓库的必需契约来使状态变绿。
在每台主机上使用同一工作线程策略。 外层门禁并发与内层工具工作线程在 Linux、Windows 和标准运行器上的争用方式不同；按主机实测的上限可以避免新增核心反而拖慢执行。
后果
普通拉取请求会将企业级运行器容量用于 Linux 关键路径，而 Wine 托管的 Windows 作业让其判定保持在标准 Linux 运行器分配上。一次实际的分支头精确运行能够证明分支保护使用的同一组命令；排队延迟与每个作业从 startedAt 到 completedAt 的执行区间分开报告。
企业级运行器分配能力下降时，标准兼容性作业和必需的 Windows 作业仍能提供有用证据，但无法让受阻的必需 Linux 作业或聚合流程变绿。恢复 Linux 可用性时，可能需要恢复完整的标准托管拓扑；仅改变运行器池定义的状态，不足以证明它可以接收作业。