parameterized default choices not passing on SCM triggered builds

89 views
Skip to first unread message

John Chittum

unread,
Dec 9, 2015, 4:34:16 PM12/9/15
to Jenkins Users

Running into a problem specifically with SCM change triggered builds


Specs:


Jenkins 1.596.2

Git Plugin 2.4.0

Git Client Plugin 1.19.0


Builds triggered via SCM change start normally-a commit notification is displayed, the branches are pulled, and it runs smoothly until the build step.


All builds are parameterized builds. Maven builds have an Extensible Choice, MVN_GOALS. All builds have a Boolean Choice for DISABLE_SONAR.


We set the parameters as follows:


    <true> This build is parameterized

Extensible Choice

Name: MVN_GOALS

Description: Choose your build goals

Choice Provider: Textarea Choice Parameter

Choices: clean deploy

        clean deploy -Prelease (this uses a specific release profile we have set-up)

Default Choice: clean deploy

Editable <true>

Boolean Parameter

Name: DISABLE_SONAR

Default Value <true>


On a build triggered via SCM change from Atlassian Stash, the default choice for MVN_GOALS is not being passed. Specifically we're seeing:




<===[JENKINS REMOTING CAPACITY]===>channel started

Executing Maven:  -B -f /var/lib/jenkins/workspace/service-engine-core-master/pom.xml -Dmaven.repo.local=/var/lib/jenkins/maven-repositories/1 $MVN_GOALS



[ERROR] Unknown lifecycle phase "$MVN_GOALS". You must specify a valid lifecycle phase or a goal in the format <plugin-prefix>:<goal> or <plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal>. Available lifecycle phases are: validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy, pre-clean, clean, post-clean, pre-site, site, post-site, site-deploy. -> [Help 1]





We first saw the issue relating to the DISABLE_SONAR parameter for non-Maven builds (where it defaults to <true>, meaning no Sonar). Sonar was arbitrarily running. I found in a freestyle project, adding a build step of “Shell”: env, which just prints the environment variables, actually works. However with a Maven build, I can’t add a build step, and running env as a pre-build step, it failed to list MVN_GOALS or DISABLE_SONAR.


 This only happens with builds triggered via SCM, which means using the default value. Manual builds, when a choice is made, it runs. Timed builds have also been running fine, as well as downstream builds. 


any info is good info. Thanks!

Mark Waite

unread,
Dec 9, 2015, 4:43:28 PM12/9/15
to Jenkins Users
That's a bug introduced in git plugin 2.4.0.  One way to avoid the bug is to revert to git plugin 2.3.5.

The bug is only visible when the "sha1=xxx" parameter is included in the notify commit URL.  One way to avoid the bug is to configure Stash to not include sha1=xxx in the notify commit message.

The bug is fixed on the current master branch of the git plugin.  You could install a pre-release of the git plugin to confirm it is resolved for your use case.


Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/cf31bc4e-dd57-4aec-9c67-80d032a865c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

John Chittum

unread,
Dec 9, 2015, 6:04:52 PM12/9/15
to Jenkins Users
Thanks for the quick reply! We've reverted to 2.3.5 for the moment. 

John C
Reply all
Reply to author
Forward
0 new messages