Has nothing to do with folders or build flow.

The current behavior seems sane, as it only provides parameters currently defined on job (i.e. its contract). This is the resilient option in the face of job configuration changes between the time a build was started and when a user tries to rebuild, so that when a parameter is removed or renamed, it will no longer be part of "rebuild".

Considering both behaviors, the current one seems to be less surprising.

If a build script accesses certain parameters, why not just define them on the job running the build script?

If it has nothing to do with folders, then why is the behavior of the plugin different depending on whether the job is in a folder or not?

If the job is not in a folder, "Rebuild Last" supplies all the job parameters--including any parameters passed in by a triggering job.
If the job is in a folder, "Rebuild Last" only supplies parameters that are explicitly defined in that particular job.

In both cases, clicking the last successful build drop-down menu in the built-jobs list and picking "Parameters" displays all the parameters that were effective in that particular job run--whether they were passed in by a triggering job, or defined explicitly in the job itself. Why would these parameters get evicted when you want to do a rebuild? That simply doesn't follow for me.

Having triggered jobs always explicitly define every parameter they rely on can result in significant multiplication of maintenance effort across many dozens of jobs. Sometimes it's just a lot easier to pass in some suite-global params from a parent job.

Unfortunately this report provides basically no information required to reproduce an issue (Jenkins version, plugin versions, exact steps to reproduce...), so I cannot comment on what you're seeing.

On Jenkins 1.576 with Build Flow 0.12 and Rebuilder 1.22, I tried the following:

• Create a freestyle job named "Jenkins-24468" with the string parameter "foo"
• Create a build flow with the DSL: build('JENKINS-24468', foo: 'flowfoo', bar: 'flowbar')
• Launch the build flow and wait until the JENKINS_24468 build finishes
• Check its parameters: Both foo and bar are set.
• Go to /job/JENKINS-24468 and click 'Rebuild Last': it only displays 'foo' with value 'flowfoo'.

Weirdly enough both parameters (both the "defined" one and the "undefined" one) are passed when the option "Rebuild Without Asking For Parameters" is set. However that also applies to a copy of the same job in a folder. So being inside a folder has no influence on the behavior.

In both cases, clicking the last successful build drop-down menu in the built-jobs list and picking "Parameters" displays all the parameters that were effective in that particular job run--whether they were passed in by a triggering job, or defined explicitly in the job itself. Why would these parameters get evicted when you want to do a rebuild? That simply doesn't follow for me.

Since there is no way you could pass parameters to a build when they're not defined on the job in Jenkins itself (without plugins circumventing this restriction), any parameters recorded for a build that are not defined on the job can be assumed to be obsolete for any future job executions due to reconfiguration of the job's parameters in the mean time.

Having triggered jobs always explicitly define every parameter they rely on can result in significant multiplication of maintenance effort across many dozens of jobs. Sometimes it's just a lot easier to pass in some suite-global params from a parent job.

There are several plugins that allow programmatic job configuration, like Job DSL plugin, or Jenkins Enterprise's Template plugin. Maybe that's an option for you.

Thanks for the response Daniel.

I now see that this is not a folders plugin related issue, but appears to be a Jenkins version issue.

My initial efforts were on a Jenkins OSS version 1.569 using Rebuilders plugin version 1.21. This was a folder-less setup.
My folderized tests system is a Jenkins Enterprise version 1.574 using Rebuilders 1.21. This is the folderized setup.
Since the Jenkins versions were pretty close, i didn't expect different behavior based on the Jenkins version, but in fact that seems to be the case.

To simplify the test i made two new free-style jobs at the top level of Jenkins instances.
"Trigger Source" has one String parameter "TEST_PARAM" default value = "Got it?".
"Trigger Target" job is just a a new free style with no changes.
"Trigger Source" triggers "Trigger Target" with Add Paramters/Current build parameters.

After one time launch of "Trigger Source" on the 1.569 instance, doing Rebuild Last on the "Trigger Target"displays the TEST_PARAM passed in, but on the 1.574 Enterprise instance, rebuilding the "Trigger Target" job does not display or pass the previously passed in TEST_PARAM.

I'll do some additional testing on the Jenkins versions in-between these two, and also OSS vs. Enterprise to see if i can isolate where the change occurred.

It appears that this is also not connected to the Jenkins version, but has been working for us due to a magical combination of plugins on our release build system.

I will still argue that the goal of the Rebuild plugin is to rebuild the last run of the job using the same parameters that job run used (whether they are configured in the job or not) and that the rebuild should use the parameter list one sees with http://jenkins-url/job/job-name/1/parameters/

I am now assuming that we can achieve the desired behavior by matching a required plugin set. If that proves impossible to replicate we can attempt to enhance the Rebuild plugin to support this capability.

Ok, this is actually just a regression in the Rebuild plugin from version 1.21 to 1.22.

Version 1.22 does not work as expected. Version1.21 does.

I had used Jenkins Plugin Manager to downgrade the plugin from 122 to 1.21 on the new folderized test system, but that did not cure it. I had to blow away the rebuild plugin directory from the Jenkins home plugins folder and do a fresh install of version 1.21 to get rid of the issue.