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

Tools should allow variables in their names for declarative pipeline

      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

          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 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 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.

          Code changed in jenkins
          User: Andrew Bayer
          Path:
          pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Tools.groovy
          pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/parser/RuntimeASTTransformer.groovy
          pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/validator/ModelValidatorImpl.groovy
          pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy
          pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/ToolsTest.java
          http://jenkins-ci.org/commit/pipeline-model-definition-plugin/9b0ae5e67808bd5cc64bdb792e0e475ed833ce4d
          Log:
          [FIXED JENKINS-44497] Allow env vars and such in tools values.

          We can't validate those, obviously, but such is life.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Tools.groovy pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/parser/RuntimeASTTransformer.groovy pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/validator/ModelValidatorImpl.groovy pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/ToolsTest.java http://jenkins-ci.org/commit/pipeline-model-definition-plugin/9b0ae5e67808bd5cc64bdb792e0e475ed833ce4d Log: [FIXED JENKINS-44497] Allow env vars and such in tools values. We can't validate those, obviously, but such is life.

          Liam Newman added a comment -

          Bulk closing resolved issues.

          Liam Newman added a comment - Bulk closing resolved issues.

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

              Created:
              Updated:
              Resolved: