-
New Feature
-
Resolution: Unresolved
-
Major
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.
- is duplicated by
-
JENKINS-43769 Add tokens for tool installations managed by Jenkins
-
- Resolved
-
- is related to
-
JENKINS-33966 JAVA_HOME is not set when Maven is automatically installed
-
- Resolved
-
-
JENKINS-26057 Workflow build step for Maven
-
- Closed
-
-
JENKINS-30372 Workflow step that is a platform-neutral alternative for bat and sh
-
- Closed
-
-
JENKINS-35419 Allow tools to be installed automatically without global configuration
-
- Open
-
- relates to
-
JENKINS-32000 durable-task 1.7 breaks workflow bat steps
-
- Open
-
-
JENKINS-42382 AntInstallation not setting PATH+ANT
-
- Resolved
-
-
JENKINS-42381 GradleInstallation not setting PATH+GRADLE
-
- Closed
-
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:
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