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

Tools should allow variables in their names for declarative pipeline

XMLWordPrintable

      I have a parameter called JDK_TOOL and would like to use the parameter inside of my declarative pipeline tools definition but this script does not work:

      pipeline { 
 agent any
 tools { 
  jdk "${params.JDK_TOOL}"
 } 
 stages {
  stage('Example') {
   steps {
    sh 'jdk --version'
   }
  }
 }
}

      I get an error which says:

      org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: 7: Tool type "jdk" does not have an install of ""${params.JDK_TOOL}"" configured - did you mean "TEST2"? @ line 7, column 5.
   jdk "${params.JDK_TOOL}"

      so it does not seem to actually parse the variable at all(and adds the " as well)

          [JENKINS-44497] Tools should allow variables in their names for declarative pipeline

          Alex Taylor created issue -

          Patrick Wolf added a comment -

          Given the following Pipeline:

          pipeline { 
  agent any 
  parameters { 
    string(name: 'mvnTool', defaultValue: 'apache-maven-3.0.1', description: '' ) 
  } 
  tools { 
    maven "${params.mvnTool}" 
  } 
  stages { 
    stage('Example') { 
      steps { 
        sh 'mvn --version' 
      } 
    } 
  } 
}

          This will result in an unknown tool error.  

          If you remove the quotes and try it as 

          maven = params.mvnTool

          Then the Declarative parser will prepend "${ and append }" around the variable and you get the same error. It recognizes it as a variable enough to wrap it in a variable quote but does not expand it.

          I tried many various combinations of string escaping to use a variable here with no luck.

          The same is true of environment variables or trying to use the groovy variable directly without the 'params.' object.

          Patrick Wolf added a comment - Given the following Pipeline: pipeline { agent any parameters { string(name: 'mvnTool' , defaultValue: 'apache-maven-3.0.1' , description: '' ) } tools { maven "${params.mvnTool}" } stages { stage( 'Example' ) { steps { sh 'mvn --version' } } } } This will result in an unknown tool error.   If you remove the quotes and try it as  maven = params.mvnTool Then the Declarative parser will prepend "${ and append }" around the variable and you get the same error. It recognizes it as a variable enough to wrap it in a variable quote but does not expand it. I tried many various combinations of string escaping to use a variable here with no luck. The same is true of environment variables or trying to use the groovy variable directly without the 'params.' object.

          Andrew Bayer added a comment -

          Grr. More variable resolution whackiness to deal with... =)

          Andrew Bayer added a comment - Grr. More variable resolution whackiness to deal with... =)
          Andrew Bayer made changes -
          Labels New: declarative-variable-and-method-resolution
          Andrew Bayer made changes -
          Epic Link New: JENKINS-45422 [ 183590 ]

          Andrew Bayer added a comment -

          Started experimenting with this, and the pain comes on validation - we don't have access to the resolved values of environment variables at validation time, so we can't say what "$SOME_VAR" will actually be and whether it'd be a valid tool name. Got some thoughts on this.

          Andrew Bayer added a comment - Started experimenting with this, and the pain comes on validation - we don't have access to the resolved values of environment variables at validation time, so we can't say what "$SOME_VAR" will actually be and whether it'd be a valid tool name. Got some thoughts on this.
          Andrew Bayer made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Andrew Bayer made changes -
          Status Original: In Progress [ 3 ] New: In Review [ 10005 ]

          Andrew Bayer added a comment -

          PR up for this at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/190 - opted to just not validate for cases with non-literal values.

          Andrew Bayer added a comment - PR up for this at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/190 - opted to just not validate for cases with non-literal values.
          Andrew Bayer made changes -
          Remote Link New: This issue links to "PR #190 (Web Link)" [ 17616 ]

            abayer Andrew Bayer
            ataylor Alex Taylor
            Votes:
            2 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: