GitLab CI 流水线调试器

解决什么问题

一条 main 分支上的 CI 突然红了，但页面上只剩一句笼统的 job failed。你可能要翻遍几十个 job 的日志，才能区分清楚：到底是 runner 没有挂载缓存导致依赖每次都重新下载，还是上一个阶段的产物根本没被正确传递给下一个阶段，抑或只是某个 tag 上的 runner 标签写错、作业根本没被调度起来。GitLab CI 的失败原因往往分散在 .gitlab-ci.yml 的配置、job 日志和 runner 注册信息三处，人工比对非常耗时。

它如何工作

这个技能针对的就是上述排查场景，工作流可以概括为三步：

• 解析配置：读取仓库中的 .gitlab-ci.yml，提取 stages、job 的 script、artifacts、dependencies、needs、tags 以及 rules 等关键字段，还原流水线的依赖关系。
• 拉取日志：通过 GitLab REST API v4 获取失败 job 的实际输出，而不是只看 UI 上折叠的那几行。
• 归类归因：把日志中的报错模式与配置项交叉比对，重点识别三类问题——runner 未注册或标签不匹配导致的 This job is unassigned、artifacts 传递缺失或过期导致的依赖失败、以及缓存 key 设计不当导致的重复构建。

归因完成后，它会给出针对具体失败点的修复建议，而不是泛泛的「检查配置」。

适用边界与注意点

• 它只做诊断与建议，不会自动修改你的 .gitlab-ci.yml，也不负责重跑流水线，改完配置仍需你自己提交。
• 需要有效的 GitLab API 访问凭据，且账号对目标项目的 job 日志有读取权限。
• 对于自建 runner 的调度细节、include 引入的外部配置组合出的复杂继承关系，可能需要配合人工确认。
• 它不是通用的 CI 排查工具，作用域限定在 GitLab CI/CD 的流水线与 job 层面，不处理 Kubernetes 或基础设施层的问题。