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

Tools should allow variables in their names for declarative pipeline

    XMLWordPrintable

Details

    Description

      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)

      Attachments

        Issue Links

          Activity

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

            hrmpw 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.
            abayer Andrew Bayer added a comment -

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

            abayer Andrew Bayer added a comment - Grr. More variable resolution whackiness to deal with... =)
            abayer 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.

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

            abayer 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_issue_link 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.
            bitwiseman Liam Newman added a comment -

            Bulk closing resolved issues.

            bitwiseman Liam Newman added a comment - Bulk closing resolved issues.

            People

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

              Dates

                Created:
                Updated:
                Resolved: