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

Block Pipeline job while upstream or downstream projects are building

      Maybe it's just me, but I think having a possibility on Pipeline and Multibranch Pipeline projects to block execution while up- or downstream-projects are building would be beneficial, especially when migrating existing installations (see my posts in stackoverflow and in Jenkins CI).

      With Freestyle and Matrix projects there was the option of going to the "Advanced Project Options" and specify that the build should be blocked when upstream/downstream project is building. For Pipeline and Multibranch this option is unavailable, and I did not find a means of synchronizing a Pipeline/Multibranch project to existing freestyle/matrix projects without orchestrating this in another pipeline script. However, having to do that with an installation of about 400 inter-dependent projects is a huge block of work that has to be sorted out in one go. Having those "block when upstream/downstream project is building" options would allow for a gradual and smoother migration.

          [JENKINS-37718] Block Pipeline job while upstream or downstream projects are building

          Volker Gimple added a comment - - edited

          Hi Dario!

          Two days ago a comment in a related StackOverflow question popped up that you might be interested in: http://stackoverflow.com/questions/38845882/how-can-i-block-a-jenkins-2-x-pipeline-job-while-dependent-jobs-are-building?noredirect=1#comment74131469_38845882

          It seems somebody is already looking into fixing this, maybe you want to get in touch with him.

           

          Volker Gimple added a comment - - edited Hi Dario! Two days ago a comment in a related StackOverflow question popped up that you might be interested in: http://stackoverflow.com/questions/38845882/how-can-i-block-a-jenkins-2-x-pipeline-job-while-dependent-jobs-are-building?noredirect=1#comment74131469_38845882 It seems somebody is already looking into fixing this, maybe you want to get in touch with him.  

          That person is me haha! satoshi is my nickname I use sometimes... But thanks for the heads up and apologies for confusion!

          Dario Simonetti added a comment - That person is me haha! satoshi is my nickname I use sometimes... But thanks for the heads up and apologies for confusion!

          Volker Gimple added a comment -

           In that case I should apologize as well: StuporMundi is my nickname... Thanks a lot for looking into this!!!

          Volker Gimple added a comment -  In that case I should apologize as well: StuporMundi is my nickname... Thanks a lot for looking into this!!!

          Andras Gaal added a comment -

          Hi Dario,

          did you manage to work on this? Do you have any updates please?

           

           

          Andras Gaal added a comment - Hi Dario, did you manage to work on this? Do you have any updates please?    

          Hi gaalandr, unfortunately I haven't yet found time to work on this. Obviously if anyone else wants to work on this please feel free and let people know here.

          Dario Simonetti added a comment - Hi gaalandr , unfortunately I haven't yet found time to work on this. Obviously if anyone else wants to work on this please feel free and let people know here.

          Jesse Glick added a comment -

          As stated, depends on nontrivial core refactoring.

          Generally this part of core has always been rather fragile and should arguably be deprecated en masse in favor of some plugin with a fresh design.

          Jesse Glick added a comment - As stated, depends on nontrivial core refactoring. Generally this part of core has always been rather fragile and should arguably be deprecated en masse in favor of some plugin with a fresh design.

          Markus Dlugi added a comment -

          Just a heads up for people who also have the issue that too many builds are triggered when using pipelines: we implemented something similar to what the old Maven project type does in the Pipeline Maven Plugin as part of JENKINS-46313. You will need to set up your pipelines to use the withMaven() step in conjunction with its PipelineGraphPublisher feature to trigger pipeline builds when a snapshot dependency has been built. Then your pipelines will trigger each other, but the plugin will notice when a job will be triggered later on in the dependency chain, so the scenario described by dario_simonetti won't happen anymore.

          Of course, this is not a general solution since it only applies to Maven and not to other build tools such as Gradle, but it might be useful for people who are still using the Maven project type and are looking into migrating to pipeline.

          Markus Dlugi added a comment - Just a heads up for people who also have the issue that too many builds are triggered when using pipelines: we implemented something similar to what the old Maven project type does in the  Pipeline Maven Plugin as part of JENKINS-46313 . You will need to set up your pipelines to use the withMaven() step in conjunction with its PipelineGraphPublisher feature to trigger pipeline builds when a snapshot dependency has been built. Then your pipelines will trigger each other, but the plugin will notice when a job will be triggered later on in the dependency chain, so the scenario described by dario_simonetti won't happen anymore. Of course, this is not a general solution since it only applies to Maven and not to other build tools such as Gradle, but it might be useful for people who are still using the Maven project type and are looking into migrating to pipeline.

          Steve Berube added a comment -

          This would be very useful for us as well.

          Steve Berube added a comment - This would be very useful for us as well.

          Christoph Läubrich added a comment - - edited

          This would be usefull fur us as well. I'm wondering if this could be integrated in the trigger part:

           

           triggers {
                  pollSCM('H/5 * * * *')
                  upstream(upstreamProjects: "myprojectA,myprojectB", threshold: hudson.model.Result.SUCCESS), blocking: true
           }

           

          So in this case, if a scm change is detected but any of A or B are running the job is paused untill A+B finished.

          Same if A triggers the build but B is still running.

          Would this be possible? I can even try to provide a patch if someone can head me to the right direction. Where would such a change be placed?

          Christoph Läubrich added a comment - - edited This would be usefull fur us as well. I'm wondering if this could be integrated in the trigger part:    triggers {         pollSCM('H/5 * * * *')         upstream(upstreamProjects: "myprojectA,myprojectB", threshold: hudson.model.Result.SUCCESS), blocking: true   }   So in this case, if a scm change is detected but any of A or B are running the job is paused untill A+B finished. Same if A triggers the build but B is still running. Would this be possible? I can even try to provide a patch if someone can head me to the right direction. Where would such a change be placed?

          Jesse Glick added a comment -

          This is unlikely to be a simple patch. A major chunk of Jenkins core APIs would need to be refactored.

          I do not think it is worth doing anyway. Particular use cases are better handled by newer idioms, existing or to be built.

          Jesse Glick added a comment - This is unlikely to be a simple patch. A major chunk of Jenkins core APIs would need to be refactored. I do not think it is worth doing anyway. Particular use cases are better handled by newer idioms, existing or to be built.

            Unassigned Unassigned
            vgimple Volker Gimple
            Votes:
            32 Vote for this issue
            Watchers:
            39 Start watching this issue

              Created:
              Updated: