Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-44584

Parameterized builds launched by multijob phases are not properly queued

      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

          [JENKINS-44584] Parameterized builds launched by multijob phases are not properly queued

          Added some links to other defects which I suspect may be partially related to this defect in case it helps expedite the resolution.

          Kevin Phillips added a comment - Added some links to other defects which I suspect may be partially related to this defect in case it helps expedite the resolution.

          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.

          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.

          NOTE: Turns out we hit yet another problem. We are using the Jenkins Job DSL plugin to generate jobs of type 'multijob'. Well, apparently v1.21 of the multijob plugin isn't supported by the latest version of the DSL plugin. <sigh>

           

          So we are back to square one it would seem.

          Kevin Phillips added a comment - NOTE: Turns out we hit yet another problem. We are using the Jenkins Job DSL plugin to generate jobs of type 'multijob'. Well, apparently v1.21 of the multijob plugin isn't supported by the latest version of the DSL plugin. <sigh>   So we are back to square one it would seem.

          Closing issue as part of tikal-multijob-plugin issues cleanup.
          If still relevant, please open a matching issue in https://github.com/jenkinsci/tikal-multijob-plugin/issues (you can refer to this issue in its description)

          Yoram Michaeli added a comment - Closing issue as part of tikal-multijob-plugin issues cleanup. If still relevant, please open a matching issue in https://github.com/jenkinsci/tikal-multijob-plugin/issues (you can refer to this issue in its description)

            huybrechts huybrechts
            leedega Kevin Phillips
            Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: