GitLab CI 合并流水线优化器

要解决的问题

合并请求流水线（merge train）在 GitLab 里是保护主干质量的关键路径，但它往往是整条 CI 中最慢的部分。项目规模上来之后，单次合并的 pipeline 里会堆叠大量 job：串行执行、互相等待、重复构建镜像和安装依赖。结果就是合并队列越排越长，开发者要么在等流水线时焦虑，要么等不及直接 push，主干保护反而形同虚设。

技能如何工作

这个技能通过 GitLab REST API v4 直接对接你的 GitLab 实例，核心入口是 /api/v4/projects/{id}/merge_trains。它的工作分三步：

1. 拉取合并流水线数据：按项目 ID 查询 merge train 记录，获取各次合并对应的 pipeline 详情。
2. 定位瓶颈阶段：统计每个 stage / job 的实际耗时，找出真正拖慢流水线的关键路径，而不是凭感觉猜「应该是测试太慢」。
3. 生成并行化建议：基于分析结果推荐基于 DAG 的 job 依赖（通过 needs / dependencies 关键字），让彼此独立的 job 真正并行跑起来，而不是在 stage 边界上集体空等。

适用边界与注意点

• 技能只负责分析和给出建议，不会自动改写 .gitlab-ci.yml；把建议落地仍需要人工确认。
• 需要有效的 GitLab 访问令牌，且权限范围要覆盖项目的 API 读写。
• DAG 并行化不是免费的：并行度提高后，runner 并发数、资源配额、缓存策略都得跟上，否则瓶颈只是从「等 job」变成「排队抢 runner」。
• 串行依赖有时是有意设计（比如先产出构建产物供后续 job 使用），调整依赖关系前要确认没有隐藏的时序约束。