GitLab流水线依赖追踪器

要解决的问题

当 .gitlab-ci.yml 里的 job 越来越多，needs、dependencies、artifacts 和人工 when 条件交织在一起之后，靠肉眼阅读 YAML 已经很难回答一个问题：某个阶段到底被谁挡住了？ 常见的症状是，一个本可并行的 job 被串在长长的依赖链末端，前面的 build 卡住或失败，后面几十个 stage 全部等待，CI 墙钟时间被白白吃掉。更隐蔽的是隐式依赖——通过 artifacts 传播、通过共享 runner 资源间接互斥——这些依赖不会出现在 depends_on 里，却在真实运行中造成排队。

它是怎么工作的

这个技能从实际执行数据出发，而不是静态解析 YAML：

• 调用 GitLab Jobs API 拉取 job 的历史执行记录，还原每个 job 的运行状态、耗时和上下游关系；
• 结合 pipeline graph 端点 获取 DAG 拓扑，把声明式配置与真实执行图对齐，发现两者不一致的地方；
• 在依赖链上定位阻塞并行执行的瓶颈阶段，例如单个 job 拖慢整条路径、artifact 传递造成串行化、stage 划分过粗等；
• 据此给出 DAG 重构建议，比如把可拆分的 stage 拆成并行分支、调整 needs 以缩短关键路径、减少不必要的 artifact 依赖；
• 通过 GitLab Merge Requests API，将优化报告以 MR 评论的形式贴回变更所在的位置，让 review 阶段就能看到流水线层面的改进机会。

适用边界与注意点

• 追踪结果依赖 Jobs API 与 pipeline graph 的可访问性，运行前需确认调用账号具备对应项目的 read_api / 流水线读取权限。
• 它分析的是执行层面的依赖关系；对纯静态的 YAML lint（如 key 拼写错误、语法问题），应交给专门的 lint 工具，两者互补而非替代。
• DAG 重构建议是参考性的，合并或拆分 stage 会影响缓存、artifact 传播和下游 job 的触发时机，改动前建议在分支上完整验证一遍。
• 对单分支、单 job 的微型流水线，收益有限；目标场景是 job 数量较多、存在多 stage 并行与复用的历史项目。