Jenkins Plugin 编写过程中遇到的一些坑（持续更新中）

BuildWrapper.Environment.buildEnvVars

模块：

BuildWrapper

使用频率：

高

此处坑点：

BuildWrapper.Environment 中的 buildEnvVars 方法需要注意的是它可能会在 builder 中被多次调用。例如，每一次使用 Execute Windows Batch Command 插件时都会调用 buildEnvVars 来获取当前的环境变量。

踩坑后的建议：

如构建过程中的环境变量保持不变，buildEnvVars 方法尽量使用简单的方式实现。

BuildWrapper.Environment.tearDown

模块：

BuildWrapper

使用频率：

高

此处坑点：

BuildWrapper.Environment 中的 tearDown 方法按其设计，无论在任何情况下（正常，成功，终止，异常，失败等等）都将在 builder 阶段结束后紧接着执行。但在实际使用过程中，笔者发现当 builder 中出现无法预知的 Crash 时，或者其他第三方的 BuilderWrapper 也在 tearDown 过程中出现 Crash 时，均会导致 tearDown 无法被按计划被调用。

踩坑后的建议

需要在 tearDown 内完成的重要工作，需要有更健壮的方式来保障。

BuildStepMonitor.getRequiredMonitorService()

模块：

BuildStep（含Builder, Notifier, Publisher, Recorder, Shell 等）

使用频率：

高

此处坑点：

此处是一个大坑点，Google 了一下，发现众多知名插件都曾中过招。这个方法是为了支持早期 Hudson 插件而留的。当某个 Job 的 Build 构建时，这个方法用于指定其是否依赖前序 Build 已经完成。而在较多下情况，我们的构建可能并不需要依赖前序 Build 已经完成，此时一定要返回 BuildStepMonitor.NONE。

踩坑后的建议

建议在使用此方法时，区分清楚BuildStepMonitor.BUILD，BuildStepMonitor.STEP 和 BuildStepMonitor.NONE 的区别

rootURL

模块：

All

使用频率：

低

此处坑点：

在某些时候，你编写的插件需要获取 Jenkins 所在的 rootURL 以便对外提供访问接口或者根据域名实现自定义的动态配置等等。我们可以通过接口 Jenkins.getInstance().getRootUrl() 或者 ${app.rootURL} 来获取这个信息。但是在某些情况下，由于 Jenkins无法获知自己的 rootURL，你通过这个函数获取到的可能是 Null。

踩坑后的建议

使用前，可以在 系统管理 -> 系统设置 -> Jenkins URL 中编辑保存一下，即可保证 Jenkins 能够获取到正确的 rootURL。