如何加速触发构建的‘Waiting for resources’步骤？为何该步骤有时耗时过长？

一、为何‘Waiting for resources’步骤有时耗时极长？ #

导致等待时间不稳定、有时久等的原因，大多和CI/CD系统的资源调度有关：

• 构建代理资源不足：日常构建高峰期，可用的代理节点全被占满，新任务只能排队等前面的任务释放资源，自然要等很久；低峰期代理空闲，就能立刻启动。
• 代理标签匹配限制：如果你的构建任务指定了必须用带特定标签的代理（比如需要GPU、特定操作系统的节点），而符合条件的代理数量少或者正在被占用，就会陷入等待。
• 任务优先级冲突：系统里高优先级的构建任务（比如生产部署）会插队抢占资源，低优先级的普通分支构建就会被挤到后面，等待时间拉长。
• 代理未及时释放：有些任务结束后，代理没做好清理（比如残留进程、环境没重置），看起来是空闲状态但实际无法承接新任务，导致任务一直卡着等。
• 调度策略影响：不同CI/CD系统的队列调度逻辑不同，比如FIFO（先到先得）模式下，一旦前面有长耗时任务，后面的任务都得等；如果调度逻辑有延迟，也会加剧等待。

二、如何加速‘Waiting for resources’步骤？ #

针对上面的原因，可以从这几个方向优化：

• 扩容代理资源：根据日常构建的峰值数量，增加对应的代理节点；如果是云原生CI/CD工具（比如GitLab CI、GitHub Actions），可以开启自动扩缩容，高峰期自动加代理，低峰期自动释放，节省成本又解决排队问题。
• 优化代理标签配置：检查任务的代理标签要求，能放宽的就放宽，让更多代理能承接任务；或者给更多符合条件的代理添加上所需标签，扩大可用资源池。
• 合理设置任务优先级：把紧急任务（比如生产部署、热修复构建）设为高优先级，普通的分支构建、测试任务设为低优先级，避免重要任务被阻塞；但别滥用高优先级，不然队列会彻底混乱。
• 完善代理清理机制：给代理配置构建后的自动清理脚本，确保任务结束后立刻杀掉残留进程、清理临时文件、重置环境，让代理能快速回到可用状态。
• 调整调度策略：根据所用CI/CD系统的特性优化规则，比如设置队列超时时间，避免任务无限等待；或者启用抢占式调度，让高优先级任务能暂时抢占低优先级任务的代理，之后低优先级任务再重新排队。
• 合并优化构建任务：把可以合并的小任务整合到一起，减少总任务数量；同时优化单个任务的执行流程，缩短任务耗时，让代理能更快循环处理更多任务。

内容的提问来源于stack exchange，提问作者Kevin Zhang