[JENKINS-35230] The environment variables of git plugin not working in pipeline script.

[jenkins-infra-bot]

Here is my pipeline code:

node {
    checkout changelog: true,
poll: true,
scm: [
    $class: 'GitSCM', 
    branches: [[name: "${env.gitlabSourceRepoName}/${env.gitlabSourceBranch}"]],
    doGenerateSubmoduleConfigurations: false, 
    extensions: [
[$class: 'PruneStaleBranch'],
[
    $class: 'PreBuildMerge', options: [
fastForwardMode: 'FF', 
mergeRemote: 'origin', 
mergeStrategy: 'default', 
mergeTarget: "${env.gitlabTargetBranch}"
    ]
],
[$class: 'CleanCheckout']
    ], 
    userRemoteConfigs: [
[name: 'origin', url: 'git@​gitlab.mydomain.com:user/project.git', credentialsId: '8949144f-cca9-4385-8597-ad3c14bbd7ce'],
[name: "${env.gitlabSourceRepoName}", url: "${env.gitlabSourceRepoURL}", credentialsId: '8949144f-cca9-4385-8597-ad3c14bbd7ce']
    ],
    browser: [$class: 'GitLab', repoUrl: 'http://gitlab.mydomain.com', version: '8.8']
]

    echo """
     |GIT_COMMIT: ${GIT_COMMIT}
     |GIT_BRANCH: ${GIT_BRANCH }
     """.stripMargin('|')
}

But finally it gives me this error:

groovy.lang.MissingPropertyException: No such property: GIT_BRANCH for class: WorkflowScript

Is the environment variables still working for pipeline?

---

Originally reported by abcfy2, imported from: The environment variables of git plugin not working in pipeline script.

• status: Closed
• priority: Minor
• component(s): git-plugin, workflow-scm-step-plugin
• label(s): pipeline
• resolution: Duplicate
• resolved: 2017-02-15T16:52:30+00:00
• votes: 29
• watchers: 45
• imported: 2025-12-02

Raw content of original issue

Here is my pipeline code:


node {
    checkout changelog: true,
        poll: true,
        scm: [
            $class: 'GitSCM', 
            branches: [[name: "${env.gitlabSourceRepoName}/${env.gitlabSourceBranch}"]],
            doGenerateSubmoduleConfigurations: false, 
            extensions: [
                [$class: 'PruneStaleBranch'],
                [
                    $class: 'PreBuildMerge', options: [
                        fastForwardMode: 'FF', 
                        mergeRemote: 'origin', 
                        mergeStrategy: 'default', 
                        mergeTarget: "${env.gitlabTargetBranch}"
                    ]
                ],
                [$class: 'CleanCheckout']
            ], 
            userRemoteConfigs: [
                [name: 'origin', url: 'git@gitlab.mydomain.com:user/project.git', credentialsId: '8949144f-cca9-4385-8597-ad3c14bbd7ce'],
                [name: "${env.gitlabSourceRepoName}", url: "${env.gitlabSourceRepoURL}", credentialsId: '8949144f-cca9-4385-8597-ad3c14bbd7ce']
            ],
            browser: [$class: 'GitLab', repoUrl: 'http://gitlab.mydomain.com', version: '8.8']
        ]

    echo """
             |GIT_COMMIT: ${GIT_COMMIT}
             |GIT_BRANCH: ${GIT_BRANCH }
             """.stripMargin('|')
}



But finally it gives me this error:

groovy.lang.MissingPropertyException: No such property: GIT_BRANCH for class: WorkflowScript


Is the environment variables still working for pipeline?

[jenkins-infra-bot]

• Remote link associated with this issue:

  • CloudBees Internal OSS-1639

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  abcfy2 I think this might be an unintended side effect of the changes in SECURITY-170, but I'm not absolutely sure of that.  I don't have time right now to duplicate your pipeline job setup.
  
  Please try the same setup in a Jenkins server that was started with the property 
  
  hudson.model.ParametersAction.keepUndefinedParameters=true
  
  
  It may also be that there is some mistake in your referencing GIT_BRANCH without calling it env.GIT_BRANCH.
  

abcfy2 I think this might be an unintended side effect of the changes in SECURITY-170, but I'm not absolutely sure of that. I don't have time right now to duplicate your pipeline job setup.

Please try the same setup in a Jenkins server that was started with the property

hudson.model.ParametersAction.keepUndefinedParameters=true

It may also be that there is some mistake in your referencing GIT_BRANCH without calling it env.GIT_BRANCH.

[jenkins-infra-bot]

abcfy2:

• Original comment link
• Raw content of original comment:

  Thank you. I've tried your solutions, but all of them still not working.
  
  I can use the "GIT_*" variables in the free style jobs. such as :
  
  
  branch to be published: ${GIT_BRANCH}
  
  rev: ${GIT_COMMIT}
  
  commit user: ${GIT_AUTHOR_NAME}<${GIT_AUTHOR_EMAIL}>
  
  changelog:
  ${CHANGES, showPaths=true} 
  
  
  But all the variables above cannot be used in pipeline script.
  

Thank you. I've tried your solutions, but all of them still not working.

I can use the "GIT_*" variables in the free style jobs. such as :

branch to be published: ${GIT_BRANCH}

rev: ${GIT_COMMIT}

commit user: ${GIT_AUTHOR_NAME}<${GIT_AUTHOR_EMAIL}>

changelog:
${CHANGES, showPaths=true} 

But all the variables above cannot be used in pipeline script.

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  There is an article on stackoverflow.com which seems  to indicate this is a known limitation of either pipeline or the git plugin.  Sorry, but I'm not sure which is expected to provide that.
  

There is an article on stackoverflow.com which seems to indicate this is a known limitation of either pipeline or the git plugin. Sorry, but I'm not sure which is expected to provide that.

[jenkins-infra-bot]

abcfy2:

• Original comment link
• Raw content of original comment:

  Great. It's a good way to solve this issue.
  

Great. It's a good way to solve this issue.

[jenkins-infra-bot]

rboyer:

• Original comment link
• Raw content of original comment:

  This is affecting me as well.  Does the git plugin need to be subtly adjusted to export these critical pieces of data in a new way to be accessible to serial pipeline steps?
  
  In a custom plugin triggered after the Git step, the following are the only EnvVars available:
  
  BUILD_DISPLAY_NAME=#9
  BUILD_ID=9
  BUILD_NUMBER=9
  BUILD_TAG=jenkins-pipetest-9
  BUILD_TIMESTAMP=2016-07-22 11:30:39 CDT
  BUILD_URL=http://blah:8080/job/pipetest/9/
  CLASSPATH=
  HUDSON_HOME=/var/jenkins_home
  HUDSON_SERVER_COOKIE=blah
  HUDSON_URL=http://blah:8080/
  JENKINS_HOME=/var/jenkins_home
  JENKINS_SERVER_COOKIE=blah
  JENKINS_URL=http://blah:8080/
  JOB_BASE_NAME=pipetest
  JOB_NAME=pipetest
  JOB_URL=http://blah:8080/job/pipetest/
  
  
  Since BUILD_TIMESTAMP is available, that implies the https://wiki.jenkins-ci.org/display/JENKINS/Build+Timestamp+Plugin plugin is able to inject env vars into the pipeline just fine, so it is possible.
  

This is affecting me as well. Does the git plugin need to be subtly adjusted to export these critical pieces of data in a new way to be accessible to serial pipeline steps?

In a custom plugin triggered after the Git step, the following are the only EnvVars available:

BUILD_DISPLAY_NAME=#9
BUILD_ID=9
BUILD_NUMBER=9
BUILD_TAG=jenkins-pipetest-9
BUILD_TIMESTAMP=2016-07-22 11:30:39 CDT
BUILD_URL=http://blah:8080/job/pipetest/9/
CLASSPATH=
HUDSON_HOME=/var/jenkins_home
HUDSON_SERVER_COOKIE=blah
HUDSON_URL=http://blah:8080/
JENKINS_HOME=/var/jenkins_home
JENKINS_SERVER_COOKIE=blah
JENKINS_URL=http://blah:8080/
JOB_BASE_NAME=pipetest
JOB_NAME=pipetest
JOB_URL=http://blah:8080/job/pipetest/

Since BUILD_TIMESTAMP is available, that implies the https://wiki.jenkins-ci.org/display/JENKINS/Build+Timestamp+Plugin plugin is able to inject env vars into the pipeline just fine, so it is possible.

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  rboyer nice find that the build timestamp plugin has the necessary technique in it.  Are you able to review the source code of the build timestamper plugin and submit a comparable pull request for the git plugin?
  

rboyer nice find that the build timestamp plugin has the necessary technique in it. Are you able to review the source code of the build timestamper plugin and submit a comparable pull request for the git plugin?

[jenkins-infra-bot]

rboyer:

• Original comment link
• Raw content of original comment:

  Its not possible to blend them without multiple inheritance.
  
  The timestamp plugin works via an EnvironmentContributor which is distinct from SCM: https://github.com/jenkinsci/build-timestamp-plugin/blob/master/src/main/java/com/orctom/jenkins/plugin/buildtimestamp/BuildTimestampEnvironmentContributor.java
  
  I'm a Jenkins plugin newbie, so this is pushing the limits of what I can reason about effectively. Especially with this new pipeline layer on top.
  

Its not possible to blend them without multiple inheritance.

The timestamp plugin works via an EnvironmentContributor which is distinct from SCM: https://github.com/jenkinsci/build-timestamp-plugin/blob/master/src/main/java/com/orctom/jenkins/plugin/buildtimestamp/BuildTimestampEnvironmentContributor.java

I'm a Jenkins plugin newbie, so this is pushing the limits of what I can reason about effectively. Especially with this new pipeline layer on top.

[jenkins-infra-bot]

mkobit:

• Original comment link
• Raw content of original comment:

  Looks like this may be related to https://issues.jenkins-ci.org/browse/JENKINS-36436
  
  What needs to happen to make these available in pipeline? I would hope to not have to run a sh every time I want to get the commit that triggered this pipeline.
  

Looks like this may be related to https://issues.jenkins-ci.org/browse/JENKINS-36436

What needs to happen to make these available in pipeline? I would hope to not have to run a sh every time I want to get the commit that triggered this pipeline.

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  Someone needs to research the way to publish environment variables to a pipeline, then propose a pull request (with tests) to the git plugin.  Richard Boyer suggested that the timestamp plugin knows how to provide environment variables to a pipeline, so I suggested that someone might consider that as a path to an eventual pull request.
  

Someone needs to research the way to publish environment variables to a pipeline, then propose a pull request (with tests) to the git plugin. Richard Boyer suggested that the timestamp plugin knows how to provide environment variables to a pipeline, so I suggested that someone might consider that as a path to an eventual pull request.

[jenkins-infra-bot]

paralin:

• Original comment link
• Raw content of original comment:

  Were there any updates on this? How can I determine, for example, the branch Jenkins built?
  

Were there any updates on this? How can I determine, for example, the branch Jenkins built?

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  Sorry, no progress yet.  It will arrive in the git plugin eventually, since I want access to those environment variables as part of my testing of the git plugin (and git client plugin).
  

Sorry, no progress yet. It will arrive in the git plugin eventually, since I want access to those environment variables as part of my testing of the git plugin (and git client plugin).

[jenkins-infra-bot]

clausfod:

• Original comment link
• Raw content of original comment:

  paralin: You can use env.BRANCH_NAME (Multi branch projects) or use this:
  
  
  def branchName
  if(isUnix()){
    branchName = sh(returnStdout: true, script: 'git rev-parse --abbrev-ref HEAD').trim()
  } else {
    branchName = bat(returnStdout: true, script: 'git rev-parse --abbrev-ref HEAD').trim()
  }
  
  
  
  

paralin: You can use env.BRANCH_NAME (Multi branch projects) or use this:

def branchName
if(isUnix()){
  branchName = sh(returnStdout: true, script: 'git rev-parse --abbrev-ref HEAD').trim()
} else {
  branchName = bat(returnStdout: true, script: 'git rev-parse --abbrev-ref HEAD').trim()
}

[jenkins-infra-bot]

ffittschen:

• Original comment link
• Raw content of original comment:

  clausfod git rev-parse --abbrev-ref HEAD always returns HEAD for me instead of master... I guess this happens, because Jenkins always builds with a detached HEAD as described here: JENKINS-6856
  

clausfod git rev-parse --abbrev-ref HEAD always returns HEAD for me instead of master... I guess this happens, because Jenkins always builds with a detached HEAD as described here: JENKINS-6856

[jenkins-infra-bot]

pleibiger:

• Original comment link
• Raw content of original comment:

  ffittschen Try to enable "checkout to local branch"
  

ffittschen Try to enable "checkout to local branch"