Tianyi Cui
3.2 KiB
Agent Note: 拉取请求 CI 的可移植恢复边界
Status: implemented
English | 中文
问题
分配到组织自有运行器标签的拉取请求必需作业，在 GitHub 无法为这些池分配运行器时会持续排队。工作流本身有效，GitHub 标准托管作业仍能通过，但 all checks passed 始终无法启动，原本健康的拉取请求因此无法满足分支保护要求。
账单状态正常、运行器定义处于 Ready 状态以及较高的自动扩缩容上限，都不能证明指定的运行器池可以接收作业。必需的正确性检查需要预先明确一条可移植恢复路径，即使日常低延迟路径依赖仓库外部的运行器预配也不例外。
决策
CI 在标准 ubuntu-latest 上运行 3 项必需的主 Node 24 作业，并在标准 windows-2025 上运行完整的必需 Windows 作业。静态门禁发布其完全一致的已构建目录树，供快照与产物作业使用；覆盖率作业则保持独立。这些较小主机上的顶层门禁、覆盖率、ESLint、publint 和快照回放均采用单工作线程上限。Node 22.19、Node 26 和 Python SDK 兼容性也使用标准容量。轻量级 all checks passed 聚合流程仍由单独的调度决策管理，因为它不执行代码检出或仓库门禁。
3 项 Linux 主作业、Node 兼容性、Python SDK 和 windows node 24 / complete 继续作为 all checks passed 的依赖项；为恢复可用性，没有移除任何门禁，也没有将任何门禁改为仅供观测。分支保护继续要求 e2e 和 all checks passed。
保留的性能测量结果与手动套件由大型运行器决策记录。跨平台串行参考流程继续作为独立的标准托管完整性检查。
曾考虑的替代方案
等待企业级运行器分配恢复。 未分配运行器的队列不会发出任何仓库诊断，并且可能无限期阻塞所有拉取请求，因此外部恢复不能作为正确性路径。
仅使用最小的企业级运行器池。 无论指定哪个运行器池，都要经过同一个企业级分配边界；减少核心数并不能消除导致排队的依赖。
在容量不可用时跳过检查或降低其级别。 这种方式通过丢弃证据而非执行仓库的必需契约来使状态变绿。
在标准运行器上沿用大型运行器的工作线程上限。 并发运行的仓库门禁及其内部工作线程池，可能让并发需求超过较小的内存和 CPU 配额，使可用性修复反而引发资源争用故障。
后果
普通拉取请求无需企业专用配置，即可为每项实质性作业获得运行器。一次实际的分支头精确运行能够证明分支保护使用的同一组命令，代价是在较小主机上耗时更长。
手动大型运行器基准测试即使持续排队，也不会阻塞拉取请求。只有在分支头精确作业获得非零运行器 ID 并稳定完成后，才能另行作出基于证据的决策，将大型运行器恢复到必需路径；仅改变运行器池定义的状态仍然不够。