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

start jobs only if all required labels/nodes are available

      multi-configuration jobs should not be triggered if its already known that they can not finish. This is for example the case if at least one node with a required label (aka tag) is disconnected.

          [JENKINS-7306] start jobs only if all required labels/nodes are available

          bult added a comment -

          But if some of required nodes are busy, I prefer to see job started before they become free.

          bult added a comment - But if some of required nodes are busy, I prefer to see job started before they become free.

          mbien added a comment -

          this should be at least configurable. Why should a job start if the master does not know if e.g. the SCM changed? If you have the requirement for a fast responding hudson cluster: the master could simply re-evaluate the job triggers if a node connects... but not if a node disconnects.

          mbien added a comment - this should be at least configurable. Why should a job start if the master does not know if e.g. the SCM changed? If you have the requirement for a fast responding hudson cluster: the master could simply re-evaluate the job triggers if a node connects... but not if a node disconnects.

          kbertelson added a comment -

          Maybe I don't understand your request...

          When a multi-configuration job starts, it goes into the Hudson queue. Isn't it the queue's job to sort things out? When a node is available, the next job in the queue for that node runs. When it is not available, it waits until it is available.

          We reboot slaves as part of our matrix tests, So, I would not want hudson holding off on starting back-to-back long-running multi-configuration jobs just because one node affecting one child job is offline. I expect the jobs just to hang around in the queue until the node comes back online. (Eventually, Hudson recognizes the restarted slaves and brings them back online automatically.)

          kbertelson added a comment - Maybe I don't understand your request... When a multi-configuration job starts, it goes into the Hudson queue. Isn't it the queue's job to sort things out? When a node is available, the next job in the queue for that node runs. When it is not available, it waits until it is available. We reboot slaves as part of our matrix tests, So, I would not want hudson holding off on starting back-to-back long-running multi-configuration jobs just because one node affecting one child job is offline. I expect the jobs just to hang around in the queue until the node comes back online. (Eventually, Hudson recognizes the restarted slaves and brings them back online automatically.)

          mbien added a comment -

          Sorry just realized that the description is a bit misleading. The problem is actually that hudson automatically triggers jobs as soon a workspace is empty (node disconnects).

          i try to explain it a bit better with an example.

          lets say we have a multi configuration job j1 with the labels c1, c2, c3.

          lets assume all nodes with label c3 go down.
          hudson will now automatically trigger j1.

          why? The repository hasn't changed. There was no reason to trigger a build. Its even worse if you configure hudson to lock downstream jobs if upstream jobs are building - your whole cluster can lock up in this situation. The only fix is to cancel the build or boot a node with the c3 label.

          So this issue could be addressed in at least two ways:

          • add an option which tells hudson to not interpret disconnected nodes as empty workspaces and therefore trigger jobs
          • add an option to only trigger multi config. jobs if all required nodes are reachable

          mbien added a comment - Sorry just realized that the description is a bit misleading. The problem is actually that hudson automatically triggers jobs as soon a workspace is empty (node disconnects). i try to explain it a bit better with an example. lets say we have a multi configuration job j1 with the labels c1, c2, c3. lets assume all nodes with label c3 go down. hudson will now automatically trigger j1. why? The repository hasn't changed. There was no reason to trigger a build. Its even worse if you configure hudson to lock downstream jobs if upstream jobs are building - your whole cluster can lock up in this situation. The only fix is to cancel the build or boot a node with the c3 label. So this issue could be addressed in at least two ways: add an option which tells hudson to not interpret disconnected nodes as empty workspaces and therefore trigger jobs add an option to only trigger multi config. jobs if all required nodes are reachable

          kbertelson added a comment -

          OK. Thanks for the explanation.

          I did not realize that hudson triggers jobs automatically if it detects a workspace is empty. I certainly wouldn't expect it to behave that way.

          I definitely agree that nodes being disconnected should not trigger a job.

          kbertelson added a comment - OK. Thanks for the explanation. I did not realize that hudson triggers jobs automatically if it detects a workspace is empty. I certainly wouldn't expect it to behave that way. I definitely agree that nodes being disconnected should not trigger a job.

            Unassigned Unassigned
            mbien mbien
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: