Jenkinsfile中script块内调用test()报NonSerializableException问题排查

我来帮你拆解这个问题的核心原因，以及对应的解决思路：

1. script块内vs块外调用test()的本质差异 #

Jenkins Pipeline的执行逻辑依赖CPS（Continuation-Passing Style）序列化——简单说就是流水线会定期把执行状态序列化保存，防止节点断开、重启后丢失进度。这两种调用场景的处理逻辑完全不同：

• 块外调用（比如直接在stage的steps里）：这里属于Pipeline DSL原生上下文，调用@NonCPS标记的方法时，Jenkins会把它当作一个"原子步骤"执行。执行完成后，只会序列化方法的返回值（如果有的话），不会追踪方法内部的执行细节。只要你的test()没有返回不可序列化的对象，就不会触发异常。
• script块内调用：script块是用来嵌入纯Groovy代码的，Jenkins会尝试序列化整个script块的执行上下文（包括局部变量、方法调用的临时栈信息等）。虽然test()加了@NonCPS，但在script块内调用时，方法执行过程中产生的临时对象（比如sh步骤的内部返回实例）可能被留在了序列化上下文中，而这些对象大多是不可序列化的，直接导致NonSerializableException。

你怀疑和node块有关是对的：node块强制要求执行上下文可序列化（因为节点可能随时断开重连），如果你的script块嵌套在node内部，序列化的检查会更严格，异常触发的概率也就更高。

2. 临时方案：用when条件的合理性 #

你提到用when条件作为临时解决方法是可行的——因为when属于Pipeline DSL原生上下文，它的执行逻辑会被CPS正确处理，调用@NonCPS方法时不会引入不可序列化的上下文问题。不过要注意：when的核心作用是判断stage是否执行，如果你的场景是要执行test()的业务逻辑，更合适的方式是把它放在stage的steps里（块外调用），而不是when条件中。

3. 更根本的修复建议 #

你的test()方法里调用了Jenkins DSL步骤（sh），其实不应该给它加@NonCPS注解。@NonCPS是用来标记纯Groovy工具方法的（比如字符串处理、本地计算逻辑），如果方法内部调用了Jenkins的DSL步骤（这些步骤本身是CPS转换的），加@NonCPS会让Jenkins无法正确处理这些步骤的序列化，反而引发问题。

建议调整代码结构：把纯Groovy逻辑（比如你导入的JsonSlurper解析）单独抽成@NonCPS方法，包含DSL步骤的部分保留CPS转换：

#!/usr/bin/env groovy
import groovy.json.JsonSlurper

// 纯Groovy工具方法，加@NonCPS
@NonCPS
def parseEcsOutput(String jsonStr) {
    new JsonSlurper().parseText(jsonStr)
}

// 包含DSL步骤的业务方法，不加@NonCPS
def test() {
    def ecsOutput = sh script: "aws ecs update-...", returnStdout: true
    def parsedData = parseEcsOutput(ecsOutput.trim())
    // 后续业务逻辑
}

这样既避免了纯Groovy代码的CPS转换问题，又保证了DSL步骤的正确序列化处理，script块内调用也不会再抛出异常。

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