-
Bug
-
Resolution: Postponed
-
Critical
-
None
After upgrading to a recent version of the Jenkins 2 core and several different plugins, we discovered a critical defect in the handling of queued parameterized builds that are triggered by multijob phases. I've managed to reduce the use case to this simple example:
Job A:
Type: Freestyle job
Quiet time: 30 seconds
Execute concurrent builds: checked
This Build is Parameterized -> String Parameter -> Name: MyParam
Job B:
Type: multijob
Add one phase build step with the following config:
trigger: Job A
Add Parameter -> Predefined Parameter -> MyParam=JobB
Job C:
Type: multijob
Add one phase build step with the following config:
trigger: Job A
Add Parameter -> Predefined Parameter -> MyParam=JobC
With these 3 jobs configured, manually trigger a build of Job B and Job C back to back. You will see only one instance of Job A ends up in the queue and this build is then associated with both builds of Job B and Job C. This is incorrect behavior because the input parameters are different between the two. I would expect to see 2 builds of Job A to be run - one with MyParam set to JobB and another with MyParam set to JobC.
I probably should mention that I retested this configuration with Job B and Job C of type Freestyle job and using the conventional "trigger parameterized build" publish stage and the behavior was as expected, so this problem has something to do with the way the multijob phases are trigger / queuing builds of parameterized downstream jobs.
Further, I feel the need to point out that in our case we have thousands of jobs on our build farm that leverage this particular combination of plugins to orchestrate our build pipeline, all of which are sharing different downstream jobs in this way, which is why I've set the impact to critical. It completely breaks the behavior of the downstream triggers and any subsequent build phases that depend on the output of those triggered jobs.
Our current configuration:
Jenkins LTS v2.46.1
Parameterized Trigger Plugin v2.33
Multijob Plugin v1.24
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
JENKINS-31846 MultiJob plugin should differ when the same job is used multiple times
-
- Closed
-
[JENKINS-44584] Parameterized builds launched by multijob phases are not properly queued
Kevin Phillips
created issue -
Kevin Phillips
made changes -
| Link |
New:
This issue relates to |
Kevin Phillips
made changes -
| Link |
New:
This issue relates to |
Kevin Phillips
made changes -
| Link |
New:
This issue relates to |
Kevin Phillips
made changes -
| Link |
New:
This issue relates to |
Kevin Phillips
made changes -
| Link |
New:
This issue relates to |
Kevin Phillips
added a comment - I just did some further testing, and with everything else being equal, downgrading to v1.21 of the multijob plugin seems to correct the triggering problem. It looks then that v1.22 introduced a regression that broke the triggering mechanisms somehow. Hopefully this helps narrow down the root cause.
Kevin Phillips
added a comment - I just did some further testing, and with everything else being equal, downgrading to v1.21 of the multijob plugin seems to correct the triggering problem. It looks then that v1.22 introduced a regression that broke the triggering mechanisms somehow. Hopefully this helps narrow down the root cause. Kevin Phillips
made changes -
| Description |
Original:
After upgrading to a recent version of the Jenkins 2 core and several different plugins, we discovered a critical defect in the handling of queued parameterized builds that are triggered by multijob phases. I've managed to reduce the use case to this simple example: Job A: Type: Freestyle job Quiet time: 30 seconds This Build is Parameterized -> String Parameter -> Name: MyParam Job B: Type: multijob Add one phase build step with the following config: trigger: Job A Add Parameter -> Predefined Parameter -> MyParam=JobB Job C: Type: multijob Add one phase build step with the following config: trigger: Job A Add Parameter -> Predefined Parameter -> MyParam=JobC With these 3 jobs configured, manually trigger a build of Job B and Job C back to back. You will see only one instance of Job A ends up in the queue and this build is then associated with both builds of Job B and Job C. This is incorrect behavior because the input parameters are different between the two. I would expect to see 2 builds of Job A to be run - one with MyParam set to JobB and another with MyParam set to JobC. I probably should mention that I retested this configuration with Job B and Job C of type Freestyle job and using the conventional "trigger parameterized build" publish stage and the behavior was as expected, so this problem has something to do with the way the multijob phases are trigger / queuing builds of parameterized downstream jobs. Further, I feel the need to point out that in our case we have thousands of jobs on our build farm that leverage this particular combination of plugins to orchestrate our build pipeline, all of which are sharing different downstream jobs in this way, which is why I've set the impact to critical. It completely breaks the behavior of the downstream triggers and any subsequent build phases that depend on the output of those triggered jobs. Our current configuration: Jenkins LTS v2.46.1 Parameterized Trigger Plugin v2.33 Multijob Plugin v1.24 |
New:
After upgrading to a recent version of the Jenkins 2 core and several different plugins, we discovered a critical defect in the handling of queued parameterized builds that are triggered by multijob phases. I've managed to reduce the use case to this simple example: Job A: Type: Freestyle job Quiet time: 30 seconds Execute concurrent builds: checked This Build is Parameterized -> String Parameter -> Name: MyParam Job B: Type: multijob Add one phase build step with the following config: trigger: Job A Add Parameter -> Predefined Parameter -> MyParam=JobB Job C: Type: multijob Add one phase build step with the following config: trigger: Job A Add Parameter -> Predefined Parameter -> MyParam=JobC With these 3 jobs configured, manually trigger a build of Job B and Job C back to back. You will see only one instance of Job A ends up in the queue and this build is then associated with both builds of Job B and Job C. This is incorrect behavior because the input parameters are different between the two. I would expect to see 2 builds of Job A to be run - one with MyParam set to JobB and another with MyParam set to JobC. I probably should mention that I retested this configuration with Job B and Job C of type Freestyle job and using the conventional "trigger parameterized build" publish stage and the behavior was as expected, so this problem has something to do with the way the multijob phases are trigger / queuing builds of parameterized downstream jobs. Further, I feel the need to point out that in our case we have thousands of jobs on our build farm that leverage this particular combination of plugins to orchestrate our build pipeline, all of which are sharing different downstream jobs in this way, which is why I've set the impact to critical. It completely breaks the behavior of the downstream triggers and any subsequent build phases that depend on the output of those triggered jobs. Our current configuration: Jenkins LTS v2.46.1 Parameterized Trigger Plugin v2.33 Multijob Plugin v1.24 |
Kevin Phillips
added a comment - NOTE: Anyone who does try to downgrade to v1.21 of the multijob plugin while using Jenkins 2 will also need to disable the new parameter security features introduced in Jenkins 2 as described here: https://jenkins.io/security/advisory/2016-05-11/
From what I can tell, support for these new security features was introduced in v1.22 of the plugin (https://issues.jenkins-ci.org/browse/JENKINS-36124) but that version also breaks the parameterize job triggers so this seems to be the only recipe that works given our current options. In fact, perhaps the changes made to address that defect may be to blame for the broken job triggers, not sure.
Kevin Phillips
added a comment - NOTE: Anyone who does try to downgrade to v1.21 of the multijob plugin while using Jenkins 2 will also need to disable the new parameter security features introduced in Jenkins 2 as described here: https://jenkins.io/security/advisory/2016-05-11/
From what I can tell, support for these new security features was introduced in v1.22 of the plugin ( https://issues.jenkins-ci.org/browse/JENKINS-36124 ) but that version also breaks the parameterize job triggers so this seems to be the only recipe that works given our current options. In fact, perhaps the changes made to address that defect may be to blame for the broken job triggers, not sure. 
Added some links to other defects which I suspect may be partially related to this defect in case it helps expedite the resolution.