技能介绍

问题背景

Jenkinsfile 一旦写得不规范，故障往往不在构建阶段暴露，而是在流水线真正运行时才爆出来：某个 step 早已被标记为废弃、一段 Groovy 脚本绕过了沙箱限制、或者写法命中了常见的安全反模式。等到 CI 任务跑起来再排查，代价已经花在失败的构建、被阻塞的发布和满屏的 console 日志上。

更麻烦的是，这类问题在人工 review 时很容易被忽略——尤其是脚本式流水线（Scripted Pipeline）里，逻辑分散在 node { ... }、stage { ... } 和各类闭包之间，肉眼很难系统性地核对每个 step 的合法性。

工作原理

这个技能把检查工作交给 Jenkins 自身的 Pipeline Linter API 端点，而不是自己拼一套规则引擎。具体做法是：

接收声明式（Declarative）和脚本式（Scripted）两种风格的 Jenkinsfile 作为输入；
将文件内容提交给 Jenkins Pipeline Linter API 端点进行校验；
汇总返回结果，重点标出三类问题：

- 废弃 step 用法：仍在使用已被替代、将在后续版本移除的写法；
- 安全反模式：容易引入权限滥用或注入风险的流水线结构；
- Groovy 沙箱违规：代码超出了 Jenkins 允许的 Groovy 沙箱边界。

因为校验逻辑复用了 Jenkins 原生的 Linter，检查结果和真实流水线执行时的规则保持一致，避免了自建规则库与 Jenkins 版本演进脱节的问题。

适用边界

技能依赖一个可访问的 Jenkins Pipeline Linter API 端点，上游 Jenkins 项目以 WAR、Docker 镜像、原生包和安装程序等形式提供官方发行版，需要自行保证端点可用；
它是静态校验工具，能告诉你写法是否合法、是否存在风险，但不会执行流水线，也不会替代真实的构建和集成测试；
对于 Jenkins 版本差异导致的规则变化，需要以你实际使用的 Jenkins 实例为准；
更深入的环境配置与内部机制，参见上游 Jenkins 的开发者文档和贡献指南。