Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-32435

A dash character in an environment variable causes variable to not expand

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Not A Defect
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      Windows, git executeable, jenkins 1.643, git-plugin 2.4.1
    • Similar Issues:

      Description

      We try to use the "Branches to build" setting of the GIT plugin with variable substitution.

      That it should be possible and work is stated in the inline help for this parameter:

      ${ENV_VARIABLE}
      It is also possible to use environment variables. In this case the variables are evaluated and the result is used as described above.
      E.g. ${TREEISH}, refs/tags/${TAGNAME},...
      

      We have setup our job with the flag "Prepare environment to run" and added following parameter as "Properties Content":

      GIT-RELEASE_BRANCH=refs/heads/release/20160113
      

      In the field of "Branches to build" we tried to use

      ${GIT-RELEASE_BRANCH}
      

      We have also tried

      ${ENV_GIT-RELEASE_BRANCH}
      

      We can see for a specific build that the parameter is available as "Environment Variable".

      The job log looks like this (where the parameter is not replaces by the content):

       > D:\git\cmd\git.exe rev-parse "origin/${GIT-RELEASE_BRANCH}^{commit}" # timeout=10
       > D:\git\cmd\git.exe rev-parse "${GIT-RELEASE_BRANCH}^{commit}" # timeout=10
      

      We expect, that the variable is replaced by its content and used in the git command invocation.

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment - - edited

          As far as I can tell from a first trivial test, the plugin is evaluating some environment variables for the "Branches to build" argument. Steps I took:

          1. Create a freestyle project using Git as SCM, with git://github.com/jenkinsci/git-client-plugin.git as the repository
          2. Define the branch to build as:
            $JENKINS_HOME
            
          3. Run the job, confirm that the value of $JENKINS_HOME is inserted in the build log

          I also used the brace separated form of the variable and confirmed it was expanded in the build log.

          1. Create a freestyle project using Git as SCM, with git://github.com/jenkinsci/git-client-plugin.git as the repository
          2. Define the branch to build as:
            xy${JENKINS_HOME}/zz/y
            
          3. Run the job, confirm that the value of xy$JENKINS_HOME/zz/y is inserted in the build log
          Show
          markewaite Mark Waite added a comment - - edited As far as I can tell from a first trivial test, the plugin is evaluating some environment variables for the "Branches to build" argument. Steps I took: Create a freestyle project using Git as SCM, with git://github.com/jenkinsci/git-client-plugin.git as the repository Define the branch to build as: $JENKINS_HOME Run the job, confirm that the value of $JENKINS_HOME is inserted in the build log I also used the brace separated form of the variable and confirmed it was expanded in the build log. Create a freestyle project using Git as SCM, with git://github.com/jenkinsci/git-client-plugin.git as the repository Define the branch to build as: xy${JENKINS_HOME}/zz/y Run the job, confirm that the value of xy$JENKINS_HOME/zz/y is inserted in the build log
          Hide
          markewaite Mark Waite added a comment - - edited

          A second (less trivial) test shows that the plugin is evaluating some environment variables injected by the EnvInject plugin. Steps I took:

          1. Install the EnvInject plugin and restart Jenkins
          2. Create a freestyle project using Git as SCM, with https://github.com/MarkEWaite/JENKINS-26197.git as the repository
          3. Define the branch to build as:
            $BRANCH_TO_BUILD - or - ${BRANCH_TO_BUILD}
            
          4. Select "Prepare an environment for the run", leave defaults for all values there, and set "Properties Content" to be:
            BRANCH_TO_BUILD=jenkins
            
          5. Define a post job build step with text finder and have it check the file README.md for the text JENKINS-32435

          I've attached a picture of the environment configuration I used.

          I'll also attach the job configuration file that I used.

          Show
          markewaite Mark Waite added a comment - - edited A second (less trivial) test shows that the plugin is evaluating some environment variables injected by the EnvInject plugin. Steps I took: Install the EnvInject plugin and restart Jenkins Create a freestyle project using Git as SCM, with https://github.com/MarkEWaite/JENKINS-26197.git as the repository Define the branch to build as: $BRANCH_TO_BUILD - or - ${BRANCH_TO_BUILD} Select " Prepare an environment for the run ", leave defaults for all values there, and set "Properties Content" to be: BRANCH_TO_BUILD=jenkins Define a post job build step with text finder and have it check the file README.md for the text JENKINS-32435 I've attached a picture of the environment configuration I used. I'll also attach the job configuration file that I used.
          Hide
          markewaite Mark Waite added a comment - - edited

          A third test shows that if you name the variable GIT_RELEASE_BRANCH instead of GIT-RELEASE_BRANCH, the variable is evaluated as expected. Steps I took to show the issue include:

          1. Create a freestyle project using Git as SCM, with https://github.com/MarkEWaite/JENKINS-26197.git as the repository
          2. Define branch to build as:
            $GIT_RELEASE_BRANCH - or - ${GIT_RELEASE_BRANCH}
            
          3. Select "Prepare an environment for the run", and set "Properties Content" to be:
            GIT_RELEASE_BRANCH=jenkins
            
          4. Define a post job build step with Jenkins text finder plugin and have it check the file README.md contains JENKINS-32435 as a string
          Show
          markewaite Mark Waite added a comment - - edited A third test shows that if you name the variable GIT_RELEASE_BRANCH instead of GIT-RELEASE_BRANCH, the variable is evaluated as expected. Steps I took to show the issue include: Create a freestyle project using Git as SCM, with https://github.com/MarkEWaite/JENKINS-26197.git as the repository Define branch to build as: $GIT_RELEASE_BRANCH - or - ${GIT_RELEASE_BRANCH} Select " Prepare an environment for the run ", and set "Properties Content" to be: GIT_RELEASE_BRANCH=jenkins Define a post job build step with Jenkins text finder plugin and have it check the file README.md contains JENKINS-32435 as a string
          Hide
          waffel Thomas Wabner added a comment - - edited

          First of all: many thanks for this dep analyze!

          I can confirm that it works, if I change the variable from

          GIT-RELEASE_BRANCH to GIT_RELEASE_BRANCH

          Beside: If have used a maven styled job ... but nevertheless ... in general variable substitution works in this way. I was not aware of, that in Jenkins it is required to name the variables in such style.

          If you think, also the variable
          GIT-RELEASE_BRANCH

          should also expand, we can create another JIRA issue for this.

          I would expect, that every variable with common variable patterns inside ${} should be useable?

          Show
          waffel Thomas Wabner added a comment - - edited First of all: many thanks for this dep analyze! I can confirm that it works, if I change the variable from GIT-RELEASE_BRANCH to GIT_RELEASE_BRANCH Beside: If have used a maven styled job ... but nevertheless ... in general variable substitution works in this way. I was not aware of, that in Jenkins it is required to name the variables in such style. If you think, also the variable GIT-RELEASE_BRANCH should also expand, we can create another JIRA issue for this. I would expect, that every variable with common variable patterns inside ${} should be useable?
          Hide
          markewaite Mark Waite added a comment -

          As far as I know, the git plugin uses the variable expansion facilities provided by the Jenkins core. Since

          $GIT-RELEASE_BRANCH
          

          is not expanded, I assume that is common throughout Jenkins.

          If you choose to submit a bug report to the git plugin on that variable expansion, I'll forward it to Jenkins core. If I were on the Jenkins core team (which I'm not), I would probably then close the bug report as intentionally not implemented. It is certainly your choice if you submit a bug report or not, but I don't intend to change the behavior of the git plugin in this area.

          Show
          markewaite Mark Waite added a comment - As far as I know, the git plugin uses the variable expansion facilities provided by the Jenkins core. Since $GIT-RELEASE_BRANCH is not expanded, I assume that is common throughout Jenkins. If you choose to submit a bug report to the git plugin on that variable expansion, I'll forward it to Jenkins core. If I were on the Jenkins core team (which I'm not), I would probably then close the bug report as intentionally not implemented. It is certainly your choice if you submit a bug report or not, but I don't intend to change the behavior of the git plugin in this area.

            People

            • Assignee:
              Unassigned
              Reporter:
              waffel Thomas Wabner
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: