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

Polling no longer triggers builds (regression 1.560)

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • core
    • Linux localhost.localdomain 2.6.32-431.1.2.el6.x86_64 #1 SMP Thu Dec 12 13:59:19 CST 2013 x86_64 x86_64 x86_64 GNU/Linux

      As of version 1.560, polling my private mercurial repository hosted by BitBucket no longer works. Before version 1.560 this worked as expected. Other than Jenkins itself, there were no other changes to the system. The poll configuration looks like:

      H/5 * * * *

      The "poll log" says the following:

      Started on Apr 24, 2014 8:08:05 AM
      We need to schedule a new build to get a workspace, but deferring 1,149ms in the hope that one will become available soon (all_suitable_nodes_are_offline)
      Done. Took 1 ms
      No changes
      

      The build does have a valid workspace. Doing a manual build to "get a workspace" does work but does not resolve the polling issue.

      This is a single Jenkins instance without any slaves.

      I'd be happy to provide any other logs, information, or tests required to resolve this issue.

          [JENKINS-22750] Polling no longer triggers builds (regression 1.560)

          Luke MacNeil added a comment -

          Not this bug. I was having issues because the master node was set to tied jobs only. Once I opened it up, polling began to work again. Not sure why it behaves in this way, but regardless, it was not this bug. Re-Closing.

          Luke MacNeil added a comment - Not this bug. I was having issues because the master node was set to tied jobs only. Once I opened it up, polling began to work again. Not sure why it behaves in this way, but regardless, it was not this bug. Re-Closing.

          Kirill Peskov added a comment -

          The bug is still there, easily reproducible in following configuration:

          Server: most recent Bitnami Appliance (Ubuntu-based), jenkins.war manually upgraded to 1.577
          Slaves: 1 'cloud' in-demand slave, managed by virtualbox plugin, Ubuntu 14.04 LTS x86_64 with OS 'native' LAMP stack.
          SCM: git in local network on a separate server, accessible by ssh & git
          Job: default 'free-style job', with Build Trigger set to 'Poll SCM' once per hour (doesn't matter fixed or randomized), tied by node name to the particular slave (in-demand cloud VB slave)

          Manual job triggering brings the node online and after the configured delay (3 min in my case) jenkins proceeds with the rest of the job. Changes in SCM cannot trigger the build because of typical error message mentioned above: "We need to schedule a new build to get a workspace, but deferring in the hope that one will become available soon (all_suitable_nodes_are_offline)".

          This is not just a bug, it's SEVERE failure breaking typical workflow in any cloud environment. Jenkins has to make the decision to power up slave(s) based on the results of SCM Polling, but unable to do that, because the very SCM Polling can be done only on the node(s) which are currently offline.

          Kirill Peskov added a comment - The bug is still there, easily reproducible in following configuration: Server: most recent Bitnami Appliance (Ubuntu-based), jenkins.war manually upgraded to 1.577 Slaves: 1 'cloud' in-demand slave, managed by virtualbox plugin, Ubuntu 14.04 LTS x86_64 with OS 'native' LAMP stack. SCM: git in local network on a separate server, accessible by ssh & git Job: default 'free-style job', with Build Trigger set to 'Poll SCM' once per hour (doesn't matter fixed or randomized), tied by node name to the particular slave (in-demand cloud VB slave) Manual job triggering brings the node online and after the configured delay (3 min in my case) jenkins proceeds with the rest of the job. Changes in SCM cannot trigger the build because of typical error message mentioned above: "We need to schedule a new build to get a workspace, but deferring in the hope that one will become available soon (all_suitable_nodes_are_offline)". This is not just a bug, it's SEVERE failure breaking typical workflow in any cloud environment. Jenkins has to make the decision to power up slave(s) based on the results of SCM Polling, but unable to do that, because the very SCM Polling can be done only on the node(s) which are currently offline.

          Kirill Peskov added a comment -

          The bug is still there, easily reproducible in following configuration:

          Server: most recent Bitnami Appliance (Ubuntu-based), jenkins.war manually upgraded to 1.577
          Slaves: 1 'cloud' in-demand slave, managed by virtualbox plugin, Ubuntu 14.04 LTS x86_64 with OS 'native' LAMP stack.
          SCM: git in local network on a separate server, accessible by ssh & git
          Job: default 'free-style job', with Build Trigger set to 'Poll SCM' once per hour (doesn't matter fixed or randomized), tied by node name to the particular slave (in-demand cloud VB slave)

          Manual job triggering brings the node online and after the configured delay (3 min in my case) jenkins proceeds with the rest of the job. Changes in SCM cannot trigger the build because of typical error message mentioned above: "We need to schedule a new build to get a workspace, but deferring in the hope that one will become available soon (all_suitable_nodes_are_offline)".

          This is not just a bug, it's SEVERE failure breaking typical workflow in any cloud environment. Jenkins has to make the decision to power up slave(s) based on the results of SCM Polling, but unable to do that, because the very SCM Polling can be done only on the node(s) which are currently offline.

          Kirill Peskov added a comment - The bug is still there, easily reproducible in following configuration: Server: most recent Bitnami Appliance (Ubuntu-based), jenkins.war manually upgraded to 1.577 Slaves: 1 'cloud' in-demand slave, managed by virtualbox plugin, Ubuntu 14.04 LTS x86_64 with OS 'native' LAMP stack. SCM: git in local network on a separate server, accessible by ssh & git Job: default 'free-style job', with Build Trigger set to 'Poll SCM' once per hour (doesn't matter fixed or randomized), tied by node name to the particular slave (in-demand cloud VB slave) Manual job triggering brings the node online and after the configured delay (3 min in my case) jenkins proceeds with the rest of the job. Changes in SCM cannot trigger the build because of typical error message mentioned above: "We need to schedule a new build to get a workspace, but deferring in the hope that one will become available soon (all_suitable_nodes_are_offline)". This is not just a bug, it's SEVERE failure breaking typical workflow in any cloud environment. Jenkins has to make the decision to power up slave(s) based on the results of SCM Polling, but unable to do that, because the very SCM Polling can be done only on the node(s) which are currently offline.

          Mads Nielsen added a comment -

          Hi Kiril,

          Okay that is not good, have you tried with another cloud provider plugin like amazon-aws? Since your usecase is fairly common it is pretty strange that we haven't had multiple outcries on this one since the change is more than 3 months old. Also, i do not know why that message is displayed, we have this, and in your case you should get the latter message.

                  if (isAllSuitableNodesOffline(build)) {            
                      Collection<Cloud> applicableClouds = label == null ? Jenkins.getInstance().clouds : label.getClouds();
                      return applicableClouds.isEmpty() ? WorkspaceOfflineReason.all_suitable_nodes_are_offline : WorkspaceOfflineReason.use_ondemand_slave;            
                  }
          
          

          Best regards,
          Mads

          Mads Nielsen added a comment - Hi Kiril, Okay that is not good, have you tried with another cloud provider plugin like amazon-aws? Since your usecase is fairly common it is pretty strange that we haven't had multiple outcries on this one since the change is more than 3 months old. Also, i do not know why that message is displayed, we have this, and in your case you should get the latter message. if (isAllSuitableNodesOffline(build)) { Collection<Cloud> applicableClouds = label == null ? Jenkins.getInstance().clouds : label.getClouds(); return applicableClouds.isEmpty() ? WorkspaceOfflineReason.all_suitable_nodes_are_offline : WorkspaceOfflineReason.use_ondemand_slave; } Best regards, Mads

          Daniel Beck added a comment -

          kirill_aga: Please file a new issue. Yours is only superficially similar to this one, and we don't need to keep the ~80 people watching this one informed about the investigation related to your (different) issue.

          Daniel Beck added a comment - kirill_aga : Please file a new issue. Yours is only superficially similar to this one, and we don't need to keep the ~80 people watching this one informed about the investigation related to your (different) issue.

          Kurt Nuke added a comment -

          I am seeing this issue on an upgrade to Jenkins ver. 1.651.2 – For us, this is still a critical bug.

          Kurt Nuke added a comment - I am seeing this issue on an upgrade to Jenkins ver. 1.651.2 – For us, this is still a critical bug.

          Daniel Beck added a comment -

          kurt: Whatever you're seeing is almost guaranteed a different issue.

          Daniel Beck added a comment - kurt : Whatever you're seeing is almost guaranteed a different issue.

          Kurt Nuke added a comment -

          danielbeck Sadly not, exact same error message and SCM polling is not working on just a few builds, randomly. This seemed to occur after a node died due to hw issues. Still having the same issue.

          Kurt Nuke added a comment - danielbeck Sadly not, exact same error message and SCM polling is not working on just a few builds, randomly. This seemed to occur after a node died due to hw issues. Still having the same issue.

          Kurt Nuke added a comment -

          danielbeck Should I make a new issue for this – I can provide any information needed, though the issues are very similar.

          Kurt Nuke added a comment - danielbeck Should I make a new issue for this – I can provide any information needed, though the issues are very similar.

          Daniel Beck added a comment -

          kurt Would be best, I think.

          Daniel Beck added a comment - kurt Would be best, I think.

            arov Alex Rovner
            jdufresne Jon Dufresne
            Votes:
            43 Vote for this issue
            Watchers:
            75 Start watching this issue

              Created:
              Updated:
              Resolved: