Rather than

      withEnv(["PATH=${tool 'Maven 3.2.2'}/bin:${env.PATH}"]) {sh 'mvn package'}
      

      you should be able to say

      withTool('Maven 3.2.2') {sh 'mvn package'}
      

      where this code builds the environment variables within the block.

          [JENKINS-28718] withTool

          James Strachan added a comment - - edited

          rather than globally configuring tools; it would be nice if a workflow could define the exact versions of tools it requires and cause them to be installed on the fly. So rather than using the globally installed tool IDs it might be nice to have something like:

          withTool('maven', '3.2.2') {
            sh 'mvn package'
          }
          

          then if version 3.2.2 is not installed yet, it would cause that version of maven to be installed.

          The DSL would then need to know how to install a specific version of common tools like maven / gradle etc. (e.g. using a template blob of XML which is parameterised by the version requested).

          This would allow the workflow scripts to be in charge of what versions of tools they need; and not require global installations to be setup first. Kinda microservicey way of defining tools

          James Strachan added a comment - - edited rather than globally configuring tools; it would be nice if a workflow could define the exact versions of tools it requires and cause them to be installed on the fly. So rather than using the globally installed tool IDs it might be nice to have something like: withTool( 'maven' , '3.2.2' ) { sh 'mvn package ' } then if version 3.2.2 is not installed yet, it would cause that version of maven to be installed. The DSL would then need to know how to install a specific version of common tools like maven / gradle etc. (e.g. using a template blob of XML which is parameterised by the version requested). This would allow the workflow scripts to be in charge of what versions of tools they need; and not require global installations to be setup first. Kinda microservicey way of defining tools

          Jesse Glick added a comment -

          jstrachan yes it could perhaps encode a ToolInstaller, but if this is your goal then (at least for Linux builds) you are better off just using the CloudBees Docker Workflow plugin, which lets you define the complete build environment as part of your script.

          Jesse Glick added a comment - jstrachan yes it could perhaps encode a ToolInstaller , but if this is your goal then (at least for Linux builds) you are better off just using the CloudBees Docker Workflow plugin, which lets you define the complete build environment as part of your script.

          Thanks and totally agreed - I'd prefer Docker Workflow!

          Its mostly the complexity of getting Docker Workflow working nicely in Kubernetes (see JENKINS-29342) that prompted me to go down the withTool hack

          James Strachan added a comment - Thanks and totally agreed - I'd prefer Docker Workflow! Its mostly the complexity of getting Docker Workflow working nicely in Kubernetes (see JENKINS-29342 ) that prompted me to go down the withTool hack

          better yet would be if the tool step would simply add the correct directory to the platforms path variable inside the node it is called. This would also benefit https://issues.jenkins-ci.org/browse/JENKINS-30372

          Ing. Christoph Obexer added a comment - better yet would be if the tool step would simply add the correct directory to the platforms path variable inside the node it is called. This would also benefit https://issues.jenkins-ci.org/browse/JENKINS-30372

          Jesse Glick added a comment -

          The behavior of the existing tool step will not be changed. New steps (or step options) may be added. Anyway modifying the global env.PATH is a poor idea since it does not work for scripts doing multiple things concurrently on different nodes.

          Jesse Glick added a comment - The behavior of the existing tool step will not be changed. New steps (or step options) may be added. Anyway modifying the global env.PATH is a poor idea since it does not work for scripts doing multiple things concurrently on different nodes.

          Andrew Bayer added a comment -

          Agreed. There's real value in tool just installing the tool - in case you've got multiple versions of a tool used in the same workflow/node.

          Andrew Bayer added a comment - Agreed. There's real value in tool just installing the tool - in case you've got multiple versions of a tool used in the same workflow/node.

          +1 for all of this but you cannot always automatically install a tool. Have a look at Oracle JDK where you need credentials and validate the terms & conditions ...
          Thus requiring that some tools are pre-installed/configured on Jenkins side will be probably always a need and in that case I would like to have the availability control as soon as possible ....

          Arnaud Héritier added a comment - +1 for all of this but you cannot always automatically install a tool. Have a look at Oracle JDK where you need credentials and validate the terms & conditions ... Thus requiring that some tools are pre-installed/configured on Jenkins side will be probably always a need and in that case I would like to have the availability control as soon as possible ....

          I've implemented a `withTool` function that we're using at Docker. It's available to our Jenkins instances via the workflow-cps-global-lib-plugin. You can see the implementation here: https://github.com/docker/jenkins-pipeline-scripts/blob/master/vars/withTool.groovy

          I'm sure it's not perfect, but it works well so far.

          Mike Dougherty added a comment - I've implemented a `withTool` function that we're using at Docker. It's available to our Jenkins instances via the workflow-cps-global-lib-plugin. You can see the implementation here: https://github.com/docker/jenkins-pipeline-scripts/blob/master/vars/withTool.groovy I'm sure it's not perfect, but it works well so far.

          Andrew Bayer added a comment -

          Ooo, nifty stuff - wanna write a blog post about your shared stuff? =)

          Andrew Bayer added a comment - Ooo, nifty stuff - wanna write a blog post about your shared stuff? =)

          Jesse Glick added a comment -

          EnvVarsForToolStep seems to do this for Declarative.

          Jesse Glick added a comment - EnvVarsForToolStep seems to do this for Declarative.

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            8 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated: