Quantcast

[URGENT] Default job parameters are not used - Bug?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[URGENT] Default job parameters are not used - Bug?

norman.baumann
Hey all,

I've noticed some strange behaviour when using the Jenkins CLI to trigger a build. I was wondering if you could please clarify if the behaviour explained below is correct or stange.

I use the CLI to trigger my project that has 3 parameter by running:
 $  java -jar jenkins-cli.jar -s $JENKINS_SERVER build $PROJECT -p param1=a -p param2=b -p param3=c

That works fine. Now, I set a default value for each parameters in the hope to not having to define each parameter on the command line:
 $  java -jar jenkins-cli.jar -s $JENKINS_SERVER build $PROJECT -p param1=a -p param3=c

It works, but unfortunately this causes Jenkins to create a new instance of the project (aka. build) with one 2 parameters defined.
I was hoping that Jenkins would check the list of expected parameters to fill out the gaps for me.

Is this a bug?

I'm looking forward to your reply.

Cheers,
Norman

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: [URGENT] Default job parameters are not used - Bug?

Adam Aquilon-2
Did you ever get a response to this problem?
Or maybe found a workaround?

We have a "Dual Jenkins" solution (master/slave) to help us handle upgrades and config changes to our jenkins instance(es) in a "safer" manner, but it relies on using JCLI as opposed to RESTful calls. This bug or shortcoming prevents us from starting to use the Dual Jenkins solution, and we *really* need the JCLI build command to retrieve default parameter values for all parameters not included as -p arguments!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: [URGENT] Default job parameters are not used - Bug?

cjo9900
Seems to be reported as JENKINS-11691 [1] linked to JENKINS-7162 [2]

As parameters are handled in the own page in the UI, which creates the ParametersAction with all of the displayed items including the defaults that are populated there is no problem.

From the CLI code it is a different case.

Just had a look at the code in the BuildCommand.java [3], and in this case it just checks that the parameter name passed in is correct, there is no checking of all the parameter definitions that are attached to the project to get the missing entries.

            for (Entry<String, String> e : parameters.entrySet()) {
                String name = e.getKey();
                ParameterDefinition pd = pdp.getParameterDefinition(name);
                if (pd==null)
                    throw new AbortException(String.format("\'%s\' is not a valid parameter. Did you mean %s?",
                            name, EditDistance.findNearest(name, pdp.getParameterDefinitionNames())));
                values.add(pd.createValue(this,e.getValue()));
            }
            
            a = new ParametersAction(values);


This should add the missing parameters using the default values.


On Tuesday, August 14, 2012 1:17:49 PM UTC+1, Adam Aquilon wrote:
Did you ever get a response to this problem?
Or maybe found a workaround?

We have a "Dual Jenkins" solution (master/slave) to help us handle upgrades and config changes to our jenkins instance(es) in a "safer" manner, but it relies on using JCLI as opposed to RESTful calls. This bug or shortcoming prevents us from starting to use the Dual Jenkins solution, and we *really* need the JCLI build command to retrieve default parameter values for all parameters not included as -p arguments!

Loading...