技能介绍

它解决什么问题

CI 流水线跑了两三年之后，Jenkinsfile 往往处于一种「没人敢动、也没人愿意读」的状态。变量名含糊、阶段职责混杂、凭据明文写在脚本里、retry 和 timeout 随意堆叠——这些反模式不会让流水线立刻失败，却会在某次 Jenkins 升级、节点迁移或并行度调整时集中爆发。人工 Review 这类脚本时，审查者需要同时记住 Pipeline 共享库的最佳实践、Jenkins 安全插件的约束和 Groovy 的运行时行为，很容易漏掉隐蔽问题。

核心能力与工作方式

这个代理把 Jenkinsfile 和 Groovy 流水线脚本的审查交给Jenkins Pipeline Linter API与静态分析规则共同处理，覆盖三个常见维度：

反模式识别：阶段划分不合理、脚本式与声明式混用、隐式依赖上一个 stage 的产物、循环依赖的阶段结构等。
安全问题：凭据硬编码、未使用 withCredentials 包裹的秘密、任意 shell 注入风险、对不受信任输入缺少校验。
性能瓶颈：重复拉取依赖、在 agent 上做重活而未拆分、input/waitUntil 阻塞过长、未复用工作空间的清理策略。

审查流程大致是：先解析脚本结构，再调用 Linter API 得到诊断信息，最后由静态规则补充上下文层面的判断，例如某个 sh 命令是否命中已知的危险模式。输出以文件加行号的形式定位问题，方便直接跳转修复。

适用边界与注意点

需要明确的是，它只覆盖脚本层的静态审查。Linter API 不会真正执行流水线，因此像并行度实际表现、agent 标签匹配失败、插件版本不兼容这类运行时问题不在它的能力范围内。对于使用大量共享库的团队，代理看到的只是脚本文本，库内部逻辑需要另行测试。另外，Jenkins 官方发行版以 WAR、Docker 镜像和各平台安装包形式提供，环境中需要有可用的 Jenkins 实例或与上游一致的运行环境，才能让 Linter API 正常工作。

从工程实践看，把这类审查接入 CI 的前置步骤，比等到流水线跑红之后再排查要便宜得多；但它替代不了针对业务逻辑的 Code Review。