-
Improvement
-
Resolution: Fixed
-
Minor
-
None
-
Jenkins 2.60.3
Pipeline Maven Integration 2.0.1
mvn 3.5.3
-
-
pipeline-maven 3.10.0
Expected behavior:
In pipeline:
withMaven( maven: mvnId, // Maven installation declared in the Jenkins "Global Tool Configuration" mavenSettingsConfig: mvnSettingsId, // Maven settings.xml file defined with the Jenkins Config File Provider Plugin mavenLocalRepo: mavenLocalRepo ) { result = sh( returnStdout: true, script: 'mvn org.apache.maven.plugins:maven-help-plugin::evaluate -Dexpression=project.version -q -DforceStdout -B" ) }
Desired result variable value:
1.5.0
Actual result variable:
----- withMaven Wrapper script ----- Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) Maven home: /var/lib/jenkins/tools/hudson.tasks.Maven_MavenInstallation/mvn-3.5.3 Java version: 1.8.0_161, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.x86_64/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "3.10.0-693.17.1.el7.x86_64", arch: "amd64", family: "unix" 1.5.0
Analysis:
withMaven wrapper adds stdout info, that cannot be removed, disabled, according to source:
However, that breaks the way we gets output with mvn command.
Workaround: specifically to maven-help-plugin, I can redirect output to a file, and readFile that.
Long-term solution (exclusive choice):
- add a silent field to withMaven, to disable any output?
- add a showDebug field to show debug info
- do not show debug info, except when mvn command fails
Thank you.
- relates to
-
JENKINS-70543 Allow for the traceability option to be toggled globally
-
- Closed
-
[JENKINS-58425] withMaven prints debug log and pollutes
Very valid point. We initially focused on traceability & troubleshootability and we missed this very relevant use case.
We are doing 2 things that cause problems for your use case:
- Troubleshootability: we make visible that the `mvn` call goes through the "wrapper script" that we create to inject Maven parameters (settings files...) outputting the message "withMaven Wrapper script" (here)
- Traceability: we always add the `mvn` CLI argument `--show-version` (here)
Both should become 'optional', maybe we can even remove the troubleshootability message as the feature is mature and we have not heard of problems caused by this wrapper script.
A solution more keeping with *ix command line tooling is that this sort of additional log / debug information go to stderr, not stdout.
K P
added a comment - This indeed breaks the possibility to make easy use of the maven-help-plugin to get e.g. a pom version, pom artifact, etc. when used inside a withMaven() block.
... which is actually the method suggested here https://jenkins.io/doc/pipeline/steps/pipeline-utility-steps/#readmavenpom-read-a-maven-project-file , instead of readMavenPom. (except they don't explicitly suggest to put it inside a withMaven())
In my case, I got around this by further manipulating the variable with some Groovy code to extract the relevant part of the output. ( result.substring(result.lastIndexOf("\n") – after verifying it actually contains a newline "\n", to avoid this breaking if ever the behaviour of withMaven and its output would change again). Adding a "| tail -1" was not an option in my case, as it was running on Windows.
Note: even if this behaviour of withMaven() wouldn't be changed, it may be a good idea to inform the maintainers of the Pipeline Utility Steps so this could be indicated in their doc, as I suppose more users may struggle with this when merely following that doc?
K P
added a comment - This indeed breaks the possibility to make easy use of the maven-help-plugin to get e.g. a pom version, pom artifact, etc. when used inside a withMaven() block.
... which is actually the method suggested here https://jenkins.io/doc/pipeline/steps/pipeline-utility-steps/#readmavenpom-read-a-maven-project-file , instead of readMavenPom. (except they don't explicitly suggest to put it inside a withMaven())
In my case, I got around this by further manipulating the variable with some Groovy code to extract the relevant part of the output. ( result.substring(result.lastIndexOf("\n") – after verifying it actually contains a newline "\n", to avoid this breaking if ever the behaviour of withMaven and its output would change again). Adding a "| tail -1" was not an option in my case, as it was running on Windows.
Note: even if this behaviour of withMaven() wouldn't be changed, it may be a good idea to inform the maintainers of the Pipeline Utility Steps so this could be indicated in their doc, as I suppose more users may struggle with this when merely following that doc? 
Garr
added a comment - +1 for adding " | tail -1" to mvn help:evaluate. there is a PR : https://github.com/jenkinsci/pipeline-maven-plugin/pull/315
I assign the case to me because I don't find an account here for tkalmar
Vincent van ’t Zand
added a comment - When will this be released? I want to do exactly the same thing.
Vincent van ’t Zand
added a comment - When will this be released? I want to do exactly the same thing. Vincent van ’t Zand
added a comment - When will this be released? it was released in version 3.10 https://github.com/jenkinsci/pipeline-maven-plugin/releases/tag/pipeline-maven-3.10.0
I forgot to update the task here
Same here. I had to add " | tail -1" to my mvn help:evaluate execution.