Jenkins多分支流水线+Gitlab：如何获取MR相关CHANGE_*环境变量

我来帮你搞定这个问题——在Jenkins多分支流水线对接GitLab的合并请求（MR）场景下，要拿到你需要的那些CHANGE_*属性，核心是靠GitLab Branch Source插件的正确配置，它会自动识别GitLab的MR并注入对应的环境变量。下面一步步拆解：

一、前提条件：安装并配置GitLab Branch Source插件 #

首先确保你的Jenkins已经安装了GitLab Branch Source插件（这是关键，默认Jenkins的多分支流水线不会自动适配GitLab的MR）。安装后，在多分支流水线项目的配置页面做以下操作：

• 选择「GitLab」作为分支源，配置好GitLab服务器连接（需要提前创建GitLab的API Token，权限至少包含read_api）；
• 在「行为」区域添加「发现合并请求」的行为，根据你的需求选择合适的规则（比如“源分支与目标分支都存在”），这样Jenkins才会把GitLab的MR纳入多分支构建的范围，进而注入CHANGE_*系列变量。

二、Jenkinsfile中直接获取CHANGE_*变量 #

当插件配置正确后，GitLab的MR触发Jenkins构建时，以下环境变量会被自动注入，你可以直接通过env.变量名在Jenkinsfile中调用：

• CHANGE_ID：对应GitLab的MR编号（比如#123）
• CHANGE_URL：该MR在GitLab上的直接访问链接
• CHANGE_TITLE：MR的标题内容
• CHANGE_AUTHOR：MR提交者的GitLab用户名
• CHANGE_AUTHOR_DISPLAY_NAME：MR提交者的GitLab显示名称
• CHANGE_AUTHOR_EMAIL：MR提交者的注册邮箱
• CHANGE_TARGET：MR的目标基准分支（比如main、master）

示例Jenkinsfile代码 #

pipeline {
    agent any
    stages {
        stage('获取MR信息') {
            steps {
                script {
                    // 先判断当前是否为MR构建，避免非MR场景报错
                    if (env.CHANGE_ID) {
                        echo "✅ 当前是合并请求构建，信息如下："
                        echo "MR编号: ${env.CHANGE_ID}"
                        echo "MR链接: ${env.CHANGE_URL}"
                        echo "MR标题: ${env.CHANGE_TITLE}"
                        echo "提交者用户名: ${env.CHANGE_AUTHOR}"
                        echo "提交者显示名: ${env.CHANGE_AUTHOR_DISPLAY_NAME}"
                        echo "提交者邮箱: ${env.CHANGE_AUTHOR_EMAIL}"
                        echo "目标分支: ${env.CHANGE_TARGET}"
                    } else {
                        echo "ℹ️ 当前不是合并请求构建，跳过MR信息获取"
                    }
                }
            }
        }
        // 后续可以添加预合并构建的逻辑，比如基于CHANGE_TARGET拉取代码合并后构建
        stage('预合并构建') {
            when {
                expression { env.CHANGE_ID != null }
            }
            steps {
                script {
                    // 拉取目标分支并合并当前MR分支
                    sh "git checkout ${env.CHANGE_TARGET}"
                    sh "git merge origin/${env.CHANGE_BRANCH}"
                    // 执行你的构建命令
                    sh "./build.sh"
                }
            }
        }
    }
}

三、注意事项 #

• API Token权限：GitLab的Token必须具备足够的权限，至少要有read_api权限，否则插件无法拉取MR的详细信息，导致部分变量为空；
• 触发方式：只有当GitLab的MR有新提交自动触发Jenkins构建时，这些变量才会被注入；手动触发的构建（比如在Jenkins页面点“立即构建”）可能不会携带这些变量；
• 插件版本：尽量使用最新稳定版的GitLab Branch Source插件，旧版本可能存在变量注入不全的bug；
• 变量存在性判断：在Jenkinsfile中一定要先判断env.CHANGE_ID是否存在，再使用其他CHANGE_*变量，避免非MR构建场景下出现空指针错误。

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