You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[JENKINS-7162] specifying a cli parameter causes unspecified parameters to be blank #19735
If you have a parameterized job with multiple parameters, all with default values, you can trigger it via an upstream build and all parameters have the default value as expected. This also works when building it via the CLI if you don't specify parameters.
However as soon as you specify one parameter like "-p PARAM1=foo" then all the other parameters lose their default value and are blank for the build.
I would expect that specifying one parameter should still allow others to get the default, otherwise in our scripts that invoke CLI builds, we have to put in every parameter and duplicate the default value which is error-prone and is easy to forget when changing one. Confirmed with a fresh and clean 1.370 Hudson.
If you have a parameterized job with multiple parameters, all with default values, you can trigger it via an upstream build and all parameters have the default value as expected. This also works when building it via the CLI if you don't specify parameters.
However as soon as you specify one parameter like "-p PARAM1=foo" then all the other parameters lose their default value and are blank for the build.
I would expect that specifying one parameter should still allow others to get the default, otherwise in our scripts that invoke CLI builds, we have to put in every parameter and duplicate the default value which is error-prone and is easy to forget when changing one. Confirmed with a fresh and clean 1.370 Hudson.
I did some poking around, and it appears that the culprit is AbstractProject.scheduleBuild2. It takes a list of Actions and if it gets any parameters, only uses those, and if it doesn't get ANY, it gets all the defaults. So in there it should probably get all the defaults, then merge into that any parameters specified.
I did some poking around, and it appears that the culprit is AbstractProject.scheduleBuild2. It takes a list of Actions and if it gets any parameters, only uses those, and if it doesn't get ANY, it gets all the defaults. So in there it should probably get all the defaults, then merge into that any parameters specified.
Unfortunately the half-written patch is as much as I can understand about the build/parameter process, so if anyone is able to finish it (I think it just needs to do the merging which is over my head), that would be greatly appreciated, otherwise I am unable to fix it.
Unfortunately the half-written patch is as much as I can understand about the build/parameter process, so if anyone is able to finish it (I think it just needs to do the merging which is over my head), that would be greatly appreciated, otherwise I am unable to fix it.
Integrated in hudson_main_trunk #200[FIXED-JENKINS-7162]
Hudson ignores Maven pom.xml path when it is specified as absolute path.
Provided utility methods for checking whether a path is absolute and
absolutizing a given path (w.r.t. a base).
Provided a unit test case for this scenario (@Bug 7261).
Integrated in hudson_main_trunk #200 [FIXED-JENKINS-7162]
Hudson ignores Maven pom.xml path when it is specified as absolute path.
Provided utility methods for checking whether a path is absolute and
absolutizing a given path (w.r.t. a base).
Provided a unit test case for this scenario (@Bug 7261).
Oh and the dogfood comment about integrating a patch is most certainly not mcrooney's patch. As mcrooney mentions - it is a completely different patch for #JENKINS-7261.
Oh and the dogfood comment about integrating a patch is most certainly not mcrooney's patch. As mcrooney mentions - it is a completely different patch for #JENKINS-7261.
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 [1], 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.
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 [1], 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 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.
Add all the job defined Parameters to the ParameterAction using Defaults
if not passed via the command line.
If this breaks backwards compatibility where these are not expected to be passed, we can introduce a new option to use the defaults for parameters which triggers this behaviour.
@Option(name="-d",usage="Use defaults for parameters not specified, only valid when -p is used")
public boolean parameterDefaults = false;
Add all the job defined Parameters to the ParameterAction using Defaults
if not passed via the command line.
If this breaks backwards compatibility where these are not expected to be passed, we can introduce a new option to use the defaults for parameters which triggers this behaviour.
@Option(name="-d",usage="Use defaults for parameters not specified, only valid when -p is used")
public boolean parameterDefaults = false;
Code changed in jenkins
User: c3johnso
Path:
core/src/main/java/hudson/cli/BuildCommand.java
test/src/test/groovy/hudson/cli/BuildCommandTest.groovy
http://jenkins-ci.org/commit/jenkins/7e0d7c0acba504b8bd205cdb228346bbfa09ddfa
Log:
[FIXED JENKINS-7162] Add missing parameters as defaults when called from CLI
Add all the job defined Parameters to the ParameterAction using Defaults
if not passed via the command line.
Integrated in jenkins_main_trunk #1856[FIXED JENKINS-7162] Add missing parameters as defaults when called from CLI (Revision 7e0d7c0acba504b8bd205cdb228346bbfa09ddfa)
Activity
jenkins-infra-bot commentedon Aug 9, 2010
mcrooney:
Raw content of original comment:
I did some poking around, and it appears that the culprit is AbstractProject.scheduleBuild2. It takes a list of Actions and if it gets any parameters, only uses those, and if it doesn't get ANY, it gets all the defaults. So in there it should probably get all the defaults, then merge into that any parameters specified.
jenkins-infra-bot commentedon Aug 9, 2010
mcrooney:
Raw content of original comment:
Here is my attempt at a patch for as much as I could understand, though it still isn't doing the actual merging.
jenkins-infra-bot commentedon Aug 13, 2010
mcrooney:
Raw content of original comment:
Unfortunately the half-written patch is as much as I can understand about the build/parameter process, so if anyone is able to finish it (I think it just needs to do the merging which is over my head), that would be greatly appreciated, otherwise I am unable to fix it.
jenkins-infra-bot commentedon Aug 20, 2010
Raw content of original comment:
Integrated in
hudson_main_trunk #200
[FIXED-JENKINS-7162]
Hudson ignores Maven pom.xml path when it is specified as absolute path.
Provided utility methods for checking whether a path is absolute and
absolutizing a given path (w.r.t. a base).
Provided a unit test case for this scenario (@Bug 7261).
km :
Files :
jenkins-infra-bot commentedon Aug 20, 2010
mcrooney:
Raw content of original comment:
Hm, I'm pretty sure that comment is completely irrelevant.
jenkins-infra-bot commentedon Aug 2, 2012
Raw content of original comment:
This also affects the SSH cli access.
#
JENKINS-11691looks like a duplicate of this.jenkins-infra-bot commentedon Aug 2, 2012
Raw content of original comment:
Oh and the dogfood comment about integrating a patch is most certainly not mcrooney's patch. As mcrooney mentions - it is a completely different patch for #
JENKINS-7261.jenkins-infra-bot commentedon Aug 14, 2012
cjo9900:
Raw content of original comment:
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 [1], 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 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.
[1] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/cli/BuildCommand.java#L100
jenkins-infra-bot commentedon Aug 14, 2012
cjo9900:
Raw content of original comment:
Pull request PULL 540 added to fix this.[1]
Add all the job defined Parameters to the ParameterAction using Defaults
if not passed via the command line.
If this breaks backwards compatibility where these are not expected to be passed, we can introduce a new option to use the defaults for parameters which triggers this behaviour.
@Option(name="-d",usage="Use defaults for parameters not specified, only valid when -p is used")
public boolean parameterDefaults = false;
[1] #540
jenkins-infra-bot commentedon Aug 15, 2012
Raw content of original comment:
Code changed in jenkins
User: c3johnso
Path:
core/src/main/java/hudson/cli/BuildCommand.java
test/src/test/groovy/hudson/cli/BuildCommandTest.groovy
http://jenkins-ci.org/commit/jenkins/7e0d7c0acba504b8bd205cdb228346bbfa09ddfa
Log:
[FIXED JENKINS-7162] Add missing parameters as defaults when called from CLI
Add all the job defined Parameters to the ParameterAction using Defaults
if not passed via the command line.
jenkins-infra-bot commentedon Aug 15, 2012
Raw content of original comment:
Code changed in jenkins
User: vjuranek
Path:
core/src/main/java/hudson/cli/BuildCommand.java
test/src/test/groovy/hudson/cli/BuildCommandTest.groovy
http://jenkins-ci.org/commit/jenkins/0ddceed69f86e1e32281561873483c4dbc6ee4dd
Log:
Merge pull request #540 from cjo9900/
JENKINS-7162[FIXED JENKINS-7162] Add missing parameters as defaults when called from...
Compare: c14c761...0ddceed
jenkins-infra-bot commentedon Aug 23, 2012
Raw content of original comment:
Integrated in
jenkins_main_trunk #1856
[FIXED JENKINS-7162] Add missing parameters as defaults when called from CLI (Revision 7e0d7c0)
Result = UNSTABLE
chris.3.johnson : 7e0d7c0acba504b8bd205cdb228346bbfa09ddfa
Files :
jenkins-infra-bot commentedon Apr 24, 2013
jmechler:
Raw content of original comment:
Would love to see this backported to LTS.
jenkins-infra-bot commentedon Nov 24, 2025
[Original
is_duplicated_byfrom Jira: JENKINS-11691]