-
Bug
-
Resolution: Won't Fix
-
Critical
The bug is similar to 22750 but according to developer's request is filed here as separate issue.
It's 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 protocols
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, git polling log shows the message: "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 a sort of logical trap. Jenkins has to make the decision to power up slave node(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.
- is related to
-
-
- Closed
-
[JENKINS-24529] Poll SCM Job Trigger (git) does not wake up VirtualBox on-demand slave nodes
As far as I know, the default git polling configuration for new jobs is to perform a "fast poll" on the master machine, without requiring a slave workspace.
Kirill Peskov
added a comment - Yeah, should be. But somehow in this configuration, Jenkins simply ignores master node availability.
Kirill Peskov
added a comment - Yeah, should be. But somehow in this configuration, Jenkins simply ignores master node availability. Kirill Peskov
added a comment - BTW, could it be somehow related to the Git Repo Browser installed? I have gitlist installed, can replace it with Stash if needed.
Kirill Peskov
added a comment - BTW, could it be somehow related to the Git Repo Browser installed? I have gitlist installed, can replace it with Stash if needed. 
Nicolas Kniebihler
added a comment - I have the same issue on a similar setup :
Jenkins 1.636
Git client plugin 1.19.0
Git plugin 2.4.0
vSphere Plugin 2.6
master : Mac OS X 10.8
slave : Ubuntu 15.10, installed on an ESXi 6.0 (vSphere)
project :
- build only on Ubuntu 15.10
- get sources from a git repo on another server, connection with ssh
- branches to build : origin/* and origin/tags/*
- additional behaviors : recursive update submodules and checkout to a sub-directory (src)
- poll SCM (H/5 * * * *)
- execute a shell script to build, then archive artifacts after build (generated executable files and logs)
Nicolas Kniebihler
added a comment - I have the same issue on a similar setup :
Jenkins 1.636
Git client plugin 1.19.0
Git plugin 2.4.0
vSphere Plugin 2.6
master : Mac OS X 10.8
slave : Ubuntu 15.10, installed on an ESXi 6.0 (vSphere)
project :
build only on Ubuntu 15.10
get sources from a git repo on another server, connection with ssh
branches to build : origin/* and origin/tags/*
additional behaviors : recursive update submodules and checkout to a sub-directory (src)
poll SCM (H/5 * * * *)
execute a shell script to build, then archive artifacts after build (generated executable files and logs)
nabedge watanabe
added a comment - I have same issue.
After upgrade 1.556 to 1.653, cron polling to github.com on my build job configuration can not trigger the job saying ...
```
Started on Mar 23, 2016 10:38:00 AM
We need to schedule a new build to get a workspace, but deferring 3,693ms in the hope that one will become available soon (all_suitable_nodes_are_offline)
Done. Took 0 ms
```
If some slave node wake up, that can trigger job correctly.
nabedge watanabe
added a comment - I have same issue.
After upgrade 1.556 to 1.653, cron polling to github.com on my build job configuration can not trigger the job saying ...
```
Started on Mar 23, 2016 10:38:00 AM
We need to schedule a new build to get a workspace, but deferring 3,693ms in the hope that one will become available soon (all_suitable_nodes_are_offline)
Done. Took 0 ms
```
If some slave node wake up, that can trigger job correctly. 
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. Our users are having to start builds manually for all the effected builds. We are using Xen for our nodes.
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. Our users are having to start builds manually for all the effected builds. We are using Xen for our nodes. kurt I'm afraid that this is not likely to get any attention, even though it is a critical issue for you. I'm the current maintainer of the git plugin but don't intend to spend any time on this bug. ndeloof is not currently actively maintaining the plugin.
I'm also somewhat skeptical of this being specific to the git plugin. The git plugin does not have any code that I recognize as being able to awaken an on-demand slave node. You may want to consider assigning this bug to Jenkins core rather than the git plugin.
Kurt Nuke
added a comment - markewaite Done : https://issues.jenkins-ci.org/browse/JENKINS-34965 New issue created against Jenkins Core
Kurt Nuke
added a comment - markewaite Done : https://issues.jenkins-ci.org/browse/JENKINS-34965 New issue created against Jenkins Core 
Only a repository. Via native git protocol, e.g.
Repository URL: git://hostname/repo-name.git
Branch specifier: left blank, but has been replaced by Jenkins with '**'
Repository browser: (Auto)