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

Projects building at the same time despite "Block build when upstream is building" option

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • core
    • None
    • Windows and hudson 1.337

      If you have multiple executors (or multiple nodes) then the "Block build when upstream project is building" advanced option is not blocking downstream project during the build of upstream project. Instead, it starts the downstream project immediatelly when upstream starts to build!

      This is the opposite behaviour than help describes: "When this option is checked, Hudson will prevent the project from building when a dependency of this project is in the queue, or building."

      How to reproduce this isse:
      1. Set up 2 or more executors (the same happens with multiple slave nodes) and set quiet period to 0 (to speed up the test)
      2. Create job1 whith these settings:
      -build periodically (or SCM poll), eg. */5 * * * *
      -add a lengthy build step (eg. ping 127.0.0.1 -w 1000 -n 600)
      3. Create job2 with these settings:
      -the same build period as job1 (or at least overlap the build step of job1)
      -set a lengthy build step (eg. ping 127.0.0.1 -w 1000 -n 600)
      -under "Advanced Project Options" check the "Block build when upstream project is building" option!
      -set the "Build after other projects are built" build trigger to job1
      4. Wait until job1 starts
      5. Check job2 build history! It will start building immediatelly!

      The very same happens when you have multiple slave nodes with 1-1 executors.

          [JENKINS-5125] Projects building at the same time despite "Block build when upstream is building" option

          balazsdan added a comment -

          Unfortunately, the fix is not working for me! Tried 1.364.
          As I wrote in my previous comment, after job1 "pending - quiet period" elapsed, then job2 immediatelly starts. So job1 is still building, but job2 starts..

          balazsdan added a comment - Unfortunately, the fix is not working for me! Tried 1.364. As I wrote in my previous comment, after job1 "pending - quiet period" elapsed, then job2 immediatelly starts. So job1 is still building, but job2 starts..

          Daniel Beck added a comment -

          Is anyone still experiencing this problem on recent Jenkins versions?

          Daniel Beck added a comment - Is anyone still experiencing this problem on recent Jenkins versions?

          Jason Davis added a comment -

          Yes - 1.570 (Windows). Also left a comment in JENKINS-5150

          Jason Davis added a comment - Yes - 1.570 (Windows). Also left a comment in JENKINS-5150

          pjdarton added a comment -

          Yes.
          I have a lot of chained jobs and I've noticed that if A triggers B which triggers C, then whilst B and C won't build while A is building, they may well build whilst A is pending, and C might well start to build when A stops and just before B starts.
          i.e. it seems to be race conditions where the blocking build is stopping and another would-be-blocking build is started "not quite immediately enough".

          My setup is a Windows master and dozens of slaves (mostly Windows, some Linux). Can't remember (offhand) the version number, but it's within a month or two of the latest.

          pjdarton added a comment - Yes. I have a lot of chained jobs and I've noticed that if A triggers B which triggers C, then whilst B and C won't build while A is building, they may well build whilst A is pending, and C might well start to build when A stops and just before B starts. i.e. it seems to be race conditions where the blocking build is stopping and another would-be-blocking build is started "not quite immediately enough". My setup is a Windows master and dozens of slaves (mostly Windows, some Linux). Can't remember (offhand) the version number, but it's within a month or two of the latest.

          Daniel Beck added a comment -

          pjdarton: Seems to behave as designed. There is no guarantee AFAIK that when A finishes, B takes precedence over C. That also seems to be the problem jedavis is experiencing. Note that the original issue report is very different: In it, pjdarton's "A" and "B" would build at the same time!

          Daniel Beck added a comment - pjdarton : Seems to behave as designed. There is no guarantee AFAIK that when A finishes, B takes precedence over C. That also seems to be the problem jedavis is experiencing. Note that the original issue report is very different: In it, pjdarton's "A" and "B" would build at the same time!

          pjdarton added a comment -

          I can't comment on whether or not this is "working as designed" as I've never seen any design specifications for Jenkins, but if this is the case then it simply means that this is a design fault instead of a coding fault. It's stil a fault, it's just that the "finger of blame" points at the design/algorithm instead of the coding itself.

          e.g. I've got a build "A" that creates a library, and a build "B" which consumes that library and provides a second library, and a build "C" which consumes both of those.
          How do I tell Jenkins not to build C until after B has built, and not to build B until after A has finished building, if not through this "block build when upstead is building" option (combined with the "build this one after that one" option)? That is, after all, what that "block build" functionality is intended to give me, is it not?
          If Jenkins goes running builds on C after A but before B then, when C builds, C will get a mismatched A & B and may get a build failure (followed by a working build once the second build has gone through).

          I /had/ rather expected that, if I told Jenkins that B depended on A, and C depended on B, and not to build either B or C "whilst an upstream build was building", then that should have stopped C from building until the builds of A and B had all settled down nicely, and this is "mostly" what happens, except for some race conditions. I don't like race conditions causing my builds to go red - I want my builds to only ever go red when there's a problem with my code, not just because Jenkins built something when it shouldn't have done.
          (I have enough trouble persuading my fellow developers that red builds mean there's a problem with their code, without Jenkins causing spurious redness)

          I maintain that this is a bug - I very much doubt that this is deliberate behaviour - it makes no sense as sometimes it blocks builds and sometimes it doesn't, and it's all down to timing. A build engine like Jenkins shouldn't leave behaviour down to "timing", it should be very very predictable and leave nothing to chance.
          One should be able to check-in changes to the SCMs for A, B and C all at once to make a set of self-consistent changes, and then walk away and let Jenkins build A, then B, then C in that order.

          pjdarton added a comment - I can't comment on whether or not this is "working as designed" as I've never seen any design specifications for Jenkins, but if this is the case then it simply means that this is a design fault instead of a coding fault. It's stil a fault, it's just that the "finger of blame" points at the design/algorithm instead of the coding itself. e.g. I've got a build "A" that creates a library, and a build "B" which consumes that library and provides a second library, and a build "C" which consumes both of those. How do I tell Jenkins not to build C until after B has built, and not to build B until after A has finished building, if not through this "block build when upstead is building" option (combined with the "build this one after that one" option)? That is, after all, what that "block build" functionality is intended to give me, is it not? If Jenkins goes running builds on C after A but before B then, when C builds, C will get a mismatched A & B and may get a build failure (followed by a working build once the second build has gone through). I /had/ rather expected that, if I told Jenkins that B depended on A, and C depended on B, and not to build either B or C "whilst an upstream build was building", then that should have stopped C from building until the builds of A and B had all settled down nicely, and this is "mostly" what happens, except for some race conditions. I don't like race conditions causing my builds to go red - I want my builds to only ever go red when there's a problem with my code, not just because Jenkins built something when it shouldn't have done. (I have enough trouble persuading my fellow developers that red builds mean there's a problem with their code, without Jenkins causing spurious redness) I maintain that this is a bug - I very much doubt that this is deliberate behaviour - it makes no sense as sometimes it blocks builds and sometimes it doesn't, and it's all down to timing. A build engine like Jenkins shouldn't leave behaviour down to "timing", it should be very very predictable and leave nothing to chance. One should be able to check-in changes to the SCMs for A, B and C all at once to make a set of self-consistent changes, and then walk away and let Jenkins build A, then B, then C in that order.

          Daniel Beck added a comment -

          pjdarton: Could you please confirm the following: At no time are builds of the projects 'A', 'B', and 'C' executing at the same time. If so, what you're experiencing (execution order different from what you're expecting) is a completely different issue from the one reported here, so please file it separately. Link it to this one so others can find it more easily.

          Is anyone experiencing the issue reported here, i.e. projects with the 'Block when X is building' option set still build at the same time, in recent Jenkins versions?

          Daniel Beck added a comment - pjdarton : Could you please confirm the following: At no time are builds of the projects 'A', 'B', and 'C' executing at the same time . If so, what you're experiencing (execution order different from what you're expecting) is a completely different issue from the one reported here, so please file it separately. Link it to this one so others can find it more easily. Is anyone experiencing the issue reported here, i.e. projects with the 'Block when X is building' option set still build at the same time, in recent Jenkins versions?

          Daniel Beck added a comment -

          Changed issue title to make it clearer what exactly isn't working.

          Daniel Beck added a comment - Changed issue title to make it clearer what exactly isn't working.

          Marko Macek added a comment -

          I just encountered it now in jenkins 1.574... not sure if that's recent (it was on above date). I will upgrade it now to the latest.

          Marko Macek added a comment - I just encountered it now in jenkins 1.574... not sure if that's recent (it was on above date). I will upgrade it now to the latest.

          Three issues have been in this JIra for the longest time, all related, all major or critical, and it's still a problem to this day.  JENKINS-22800 JENKINS-5125 JENKINS-5150 

          This is a pretty commonly used feature in heavy dependency chains, without hacking my own hard to manage "Build X after passing" for every one of my jobs, can we fix this long standing problem?

           

          We are on Jenkins 2.68

          Justin Rodante added a comment - Three issues have been in this JIra for the longest time, all related, all major or critical, and it's still a problem to this day.   JENKINS-22800   JENKINS-5125   JENKINS-5150   This is a pretty commonly used feature in heavy dependency chains, without hacking my own hard to manage "Build X after passing" for every one of my jobs, can we fix this long standing problem?   We are on Jenkins 2.68

            kohsuke Kohsuke Kawaguchi
            balazsdan balazsdan
            Votes:
            15 Vote for this issue
            Watchers:
            19 Start watching this issue

              Created:
              Updated: