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

Block Build when downstream project is building

    • Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • Dependant matrix builds across Linux and Solaris

      When a downstream build is in progress, Hudson should prevent the upstream builds from occurring until the downstream build is complete.

      For example:

      CompA->CompB->CompC->CompD

      If component C is building Hudson should block builds on A and B, until C has finished.

      It should then rebuild A, B and C before allowing D to proceed.

      As the current system stands, if a user presses "build now" on component A when component C is building, A builds immediately. This can be worked around in part by using the locks & latches plugin, but this has the side affect of disabling parallel Matrix builds which massively increases the build time (see JENKINS-2725). Further, it should NOT be necessary to use ANY plugins to provide this fundamental behaviour.

          [JENKINS-7046] Block Build when downstream project is building

          aggamemnon created issue -

          Have you tried the 'Block build when upstream project is building' option in the 'Advanced project options' section of the configuration page of your job ? It does exactly what you appear to request, and we've been using it in my company successfully for quite a while now.

          Willem Verstraeten added a comment - Have you tried the 'Block build when upstream project is building' option in the 'Advanced project options' section of the configuration page of your job ? It does exactly what you appear to request, and we've been using it in my company successfully for quite a while now.

          More specifically, that option has been available for all jobs since Hudson 1.323

          Willem Verstraeten added a comment - More specifically, that option has been available for all jobs since Hudson 1.323

          aggamemnon added a comment -

          I have already set "Block build when upstream project is building" and it doesn't provide the behaviour I described in my first comment. Either it isn't intended to or it doesn't work!

          aggamemnon added a comment - I have already set "Block build when upstream project is building" and it doesn't provide the behaviour I described in my first comment. Either it isn't intended to or it doesn't work!

          After re-reading you original description, I can also confirm the bug : the 'Block build when upstream project is building' does not work transitively.

          Ie. in the example of the reporter, A is not blocked when C is building, because A does not directly depend on C, only transitively.

          We also observe this in our setup. Our hudson build is 1.376

          Willem Verstraeten added a comment - After re-reading you original description, I can also confirm the bug : the 'Block build when upstream project is building' does not work transitively. Ie. in the example of the reporter, A is not blocked when C is building, because A does not directly depend on C, only transitively. We also observe this in our setup. Our hudson build is 1.376

          Alan Harder added a comment -

          Seems like 2 different things are discussed here.. willemv's last comment refers to "block build when upstream project is building" not working transitively.. I have also observed this behavior. willemv, maybe file a new issue for this? JENKINS-5125 and JENKINS-5150 don't seem to specifically mention this..

          However, it appears to me like the original request describes blocking in the opposite direction.. "block build when downstream project is building". Hudson currently has no such feature. Can you describe why you want this? It doesn't make sense to me.. If we start the upstream job A, we know that will eventually trigger the downstream job C.. but since C has already started, there's nothing we can do at this point to avoid another build. So why block A at this point? Might as well run it in parallel with C to get all the builds completed more quickly.

          Alan Harder added a comment - Seems like 2 different things are discussed here.. willemv's last comment refers to "block build when upstream project is building" not working transitively.. I have also observed this behavior. willemv, maybe file a new issue for this? JENKINS-5125 and JENKINS-5150 don't seem to specifically mention this.. However, it appears to me like the original request describes blocking in the opposite direction.. "block build when downstream project is building". Hudson currently has no such feature. Can you describe why you want this? It doesn't make sense to me.. If we start the upstream job A, we know that will eventually trigger the downstream job C.. but since C has already started, there's nothing we can do at this point to avoid another build. So why block A at this point? Might as well run it in parallel with C to get all the builds completed more quickly.

          Hmm, I'm confused.

          The summary says : "Hudson not correctly blocking downstream builds when upstream builds in progress"
          The description says : "Hudson should prevent the upstream builds from occurring until the downstream build is complete"

          Aggamemnon, which of the two do you actually need ?

          Willem Verstraeten added a comment - Hmm, I'm confused. The summary says : "Hudson not correctly blocking downstream builds when upstream builds in progress" The description says : "Hudson should prevent the upstream builds from occurring until the downstream build is complete" Aggamemnon, which of the two do you actually need ?

          aggamemnon added a comment -

          "If we start the upstream job A, we know that will eventually trigger the downstream job C.. but since C has already started, there's nothing we can do at this point to avoid another build. So why block A at this point? Might as well run it in parallel with C to get all the builds completed more quickly."

          Comp C may depend on objects contained within A, hence if A rebuilds C will fail, or be inconsistent.

          "Aggamemnon, which of the two do you actually need ?"

          Both

          aggamemnon added a comment - "If we start the upstream job A, we know that will eventually trigger the downstream job C.. but since C has already started, there's nothing we can do at this point to avoid another build. So why block A at this point? Might as well run it in parallel with C to get all the builds completed more quickly." Comp C may depend on objects contained within A, hence if A rebuilds C will fail, or be inconsistent. "Aggamemnon, which of the two do you actually need ?" Both

          Jorg Heymans added a comment -

          mindless: imagine the case where you have a job that manipulates (e.g. destroys + rebuilds) a database schema. And then you have jobs that interact with this schema (unit,integration tests etc). Logically, the latter jobs have a dependency on the database job. We have expressed this dependency in the maven POMs, i.e. all application modules have a snapshot dependency on the database module.

          ofcourse we don't want the database job to kick in during the building of any of its downstream jobs because it would just rip out the database schema while integration tests are in progress. That's why the database job would need a "block build when downstream project is building".

          We can express this with locks and latches (urgh) or port allocator plugin but it would be a half baked job only and taking advantage of Hudson's snapshot dependency management (which is already GREAT by the way).

          I hope this clarifies the need a bit for this feature.

          Thanks
          Jorg

          Jorg Heymans added a comment - mindless: imagine the case where you have a job that manipulates (e.g. destroys + rebuilds) a database schema. And then you have jobs that interact with this schema (unit,integration tests etc). Logically, the latter jobs have a dependency on the database job. We have expressed this dependency in the maven POMs, i.e. all application modules have a snapshot dependency on the database module. ofcourse we don't want the database job to kick in during the building of any of its downstream jobs because it would just rip out the database schema while integration tests are in progress. That's why the database job would need a "block build when downstream project is building". We can express this with locks and latches (urgh) or port allocator plugin but it would be a half baked job only and taking advantage of Hudson's snapshot dependency management (which is already GREAT by the way). I hope this clarifies the need a bit for this feature. Thanks Jorg

          Jorg Heymans added a comment -

          (i took the liberty to update the subject to make it less confusing)

          Jorg Heymans added a comment - (i took the liberty to update the subject to make it less confusing)
          Jorg Heymans made changes -
          Issue Type Original: Bug [ 1 ] New: New Feature [ 2 ]
          Summary Original: Hudson not correctly blocking downstream builds when upstream builds in progress New: Block Build when downstream project is building

            Unassigned Unassigned
            aggamemnon aggamemnon
            Votes:
            21 Vote for this issue
            Watchers:
            20 Start watching this issue

              Created:
              Updated:
              Resolved: