使用注入的环境变量触发Jenkins下游任务失败问题排查

你遇到的是Jenkins环境变量作用域的典型问题：Execute Shell步骤里修改的环境变量只在当前Shell进程内有效，后续的Conditional Step是独立的进程，根本读不到你在Shell里设置的TRIGGER_JOB=true。从控制台输出也能看出来，Conditional Step依然在使用最初注入的false值。

下面给你三种可行的解决思路，按推荐程度排序：

1. 用EnvInject插件的脚本动态生成变量（最贴合你现有配置） #

不要在单独的Execute Shell里修改变量，而是直接用EnvInject的脚本功能来生成最终的TRIGGER_JOB值，这样变量会被注入到整个构建的上下文环境中，后续步骤都能读到：

• 回到test-trigger1的「Build Environment」→「Inject environment variables to the build process」配置
• 切换到「Script Content」标签，写入你的判断逻辑脚本，输出键值对格式的变量：

  # 这里替换成你实际的触发判断逻辑，比如检查构建产物、日志内容等
  if [ 你的判断条件 ]; then
      echo "TRIGGER_JOB=true"
  else
      echo "TRIGGER_JOB=false"
  fi
  

• 删除原来单独的Execute Shell步骤，直接用这个脚本生成变量即可

这样EnvInject会把脚本输出的结果作为环境变量注入，后续的Conditional Step就能拿到正确的TRIGGER_JOB值了。

2. 改用Jenkins Pipeline（最灵活可控） #

如果可以把任务改成Pipeline形式，变量的作用域问题会彻底解决，逻辑也更清晰：

pipeline {
    agent any
    environment {
        # 初始化变量默认值
        TRIGGER_JOB = 'false'
    }
    stages {
        stage('判断是否触发下游') {
            steps {
                script {
                    # 这里写你的触发判断逻辑，比如根据构建结果、文件存在性等
                    if (true) { // 替换成实际条件
                        TRIGGER_JOB = 'true'
                    }
                }
            }
        }
        stage('触发test-trigger2') {
            when {
                expression { TRIGGER_JOB == 'true' }
            }
            steps {
                build job: 'test-trigger2'
            }
        }
    }
}

Pipeline的环境变量在整个构建上下文里有效，不会有进程隔离的问题，后续维护也更方便。

3. 临时方案：用文件传递变量（不推荐，仅作应急） #

如果不想改动现有插件配置，可以通过文件传递变量值：

• 在Execute Shell步骤末尾添加：echo "true" > ${WORKSPACE}/trigger_flag.txt（根据你的判断逻辑写入true/false）
• 修改Conditional Step的Boolean condition，从读取环境变量改成读取文件内容：cat ${WORKSPACE}/trigger_flag.txt
  这种方式比较hack，容易出现权限或路径问题，仅作为临时过渡方案。

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