GitLab 流水线瓶颈分析器

痛点：流水线越来越慢，却不知道慢在哪

随着项目迭代，GitLab CI/CD 流水线通常会积累越来越多的 job 和 stage。当构建时间从几分钟变成几十分钟，团队往往只能凭经验猜测是哪个 stage 出了问题：是编译太慢？测试执行太久？还是某个 job 在等待资源？缺乏数据支撑的排查方式不仅浪费时间，还容易让团队对优化方向产生误判。

更麻烦的是，job 之间往往存在依赖关系。一个 stage 的延迟可能级联影响后续所有 job，而依赖结构通常散落在 .gitlab-ci.yml 和实际执行日志里，人工梳理成本很高。

这个技能做了什么

该技能直接调用 GitLab Pipelines API 获取流水线的完整执行数据，同时通过 Job Artifacts API 拉取作业产物信息。基于这些数据，它可以：

• 识别每个 stage 的实际耗时，定位真正的瓶颈阶段
• 分析 job 之间的依赖关系，还原执行链路
• 生成 flame-graph（火焰图） 来可视化 job 依赖与耗时分布

火焰图的优势在于，你可以一眼看出哪个分支最"宽"——也就是哪个 job 或 stage 消耗了最多时间，而不是在几十个日志文件里来回跳转。

适用边界与注意点

• 该技能依赖 GitLab API 的访问权限，需要确保运行环境具备足够的 token 权限来读取 Pipelines 和 Job Artifacts 接口
• 数据质量取决于流水线本身的配置完整性。如果 .gitlab-ci.yml 中 stage 划分混乱或 job 定义不规范，分析结果的可参考性会打折扣
• 技能基于 API 数据进行事后分析，无法替代流水线本身的监控告警体系