GitLab CI/CD 流水线优化器

要解决什么问题

GitLab CI/CD 流水线跑得慢，很多时候不是机器不够快，而是作业之间的依赖关系没有理顺。单条线性流水线里，互不依赖的测试阶段必须排队执行；大型仓库把所有检查塞进一个 .gitlab-ci.yml，merge request 的反馈周期被拉长到十几分钟甚至更久。更隐蔽的问题是隐式依赖：某个 job 依赖前一个 job 的产物，但配置里没有显式声明 needs，导致整条流水线无法并行化。

核心能力与工作方式

优化器以 .gitlab-ci.yml 规范和 GitLab API v4 为输入，主要做三件事：

• DAG 流水线：分析各 job 之间的依赖关系，显式生成 needs 声明，把可并行的路径拆出来，缩短整条流水线的关键路径。
• 并行测试：识别测试作业中的可拆分单元，利用 parallel 关键字做矩阵化拆分，让同一批测试分布到多个 runner 上同时执行。
• 动态子流水线：通过 include 与 trigger 机制，把大型流水线按阶段或模块拆成动态 child pipeline，只在相关模块变更时触发对应部分。

典型处理步骤：先通过 API v4 拉取现有 pipeline 配置与运行历史，识别瓶颈作业；再对 .gitlab-ci.yml 做结构化改写；最后验证改写后的 pipeline 语法与调度结果。

适用边界与注意点

• 优化效果取决于仓库现有的 job 拆分粒度。如果所有逻辑都堆在一个 job 的 shell 脚本里，DAG 化能做的事情有限——需要先把脚本拆成独立作业。
• GitLab API v4 需要合适的 token 权限，至少要能读取 pipeline 配置与作业日志。
• DAG 改造会改变流水线的执行顺序，合并到默认分支前建议在 MR pipeline 中完整验证一遍。
• 动态子流水线引入了额外的调度层级，调试时需要在 GitLab UI 里逐层追踪 child pipeline 的触发条件。