设置Jenkins构建状态的最佳实践：两种控制方式该如何选择？

哪种更常用？ #

常规场景下，error "错误原因"是更主流的选择。它贴合Jenkins Pipeline的原生设计，抛出错误后会立刻终止当前流水线/阶段，同时在构建日志里直接显示错误详情，排查问题时一目了然，团队内的其他开发者也更容易理解这种标准写法。

如何选择？ #

优先用error的场景 #

• 遇到明确的失败场景（比如代码编译失败、核心测试用例不通过），需要立即终止构建，同时让错误原因清晰可查时，error是最直观的选择。
• 遵循Jenkins的标准错误处理流程，避免绕过原生机制导致的意外问题（比如部分插件依赖原生错误事件触发后续通知、清理动作）。

适合用currentBuild的理由 #

虽然error是常规首选，但currentBuild有其不可替代的场景：

• 标记构建为"不稳定"而非直接失败：如果测试用例有失败但不需要中断整个流水线（比如允许部分非核心测试失败），可以用currentBuild.result = 'UNSTABLE'来标记状态，而error会直接让构建失败并终止流程，做不到这种灵活的状态标记。
• 修改已有的构建状态：比如某个阶段失败后，后续有自动修复脚本执行成功，这时可以把构建状态从"FAILURE"改回"SUCCESS"；或者中间步骤的错误属于非关键性问题，不想让整个构建失败，只是标记状态留作记录，这类场景只能通过currentBuild手动调整。
• 不终止流水线的状态标记：比如代码规范检查出现大量警告，但不影响后续构建流程，你可以设置currentBuild.result = 'UNSTABLE'来提醒开发者，同时让流水线继续执行，这是error无法实现的。

注意：尽量使用currentBuild.result = '<状态值>'而非直接操作currentBuild.rawBuild.@result，前者在声明式流水线中更安全，不需要额外的脚本权限，后者属于直接操作Jenkins内部对象，可能带来安全风险或兼容性问题。

内容的提问来源于stack exchange，提问作者okainov