Jenkins环境变量存储位置、跨构建保存方法及stash作用疑问

你观察到的env.TEST生效现象和stash完全无关，核心原因有两个：

• 你的代码里unstash envFile之后，没有执行任何读取文件内容、将变量注入到Jenkins env 对象的逻辑，所以不管这个文件存的是全量环境变量还是空文件，都不会影响你后续println env.TEST的结果
• Jenkins Pipeline原生的「从指定阶段重启」功能，默认就会自动保留上一次构建运行时的env环境变量上下文、构建参数等元数据，不需要你手动通过stash存储，这才是你从阶段2重启依然能拿到env.TEST的核心原因

补充说明：stash/untash本身是纯文件级别的操作，只会把你指定路径的文件打包/解包，不会主动读取文件内容注入环境变量，也不会自动把当前Jenkins的环境变量序列化到stash包中。如果你希望通过stash的envFile实现跨不同构建号的环境变量共享，需要在unstash之后补充变量注入逻辑，示例如下：

script {
    try {
        unstash 'envFile'
        // 新增：读取envFile内容注入到env对象
        def envProps = readProperties file: 'envFile'
        envProps.each { k, v -> env[k] = v }
    } catch(e) {
        // do something
    }
    println env.TEST
}

分为两类存储场景：

• 运行时临时存储：Pipeline执行过程中的env对象存储在Jenkins Master节点的内存中，伴随构建的生命周期存在，构建结束后内存中的数据会被清理
• 持久化存储：所有构建的环境变量会作为构建元数据持久化到磁盘，存储路径为$JENKINS_HOME/jobs/[你的任务名称]/builds/[对应构建号]/build.xml，文件内的<envVars>标签下会存储本次构建所有生效的环境变量键值对。

内容的提问来源于stack exchange，提问作者Brahim Ben Amira