[JIRA] (JENKINS-10131) Git polling shouldn't need a workspace on a slave.
Gergely Nagy commented on JENKINS-10131 Git polling shouldnt need a workspace on a slave. Seeing this with 1.1.25, with a single repo single branch (so it should work according to the above). Started on 24-Jan-2013 00:24:57 No workspace is available, so can't check for updates. Scheduling a new build to get a workspace. Done. Took 1 ms Changes found This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10131) Git polling shouldn't need a workspace on a slave.
wgracelee commented on JENKINS-10131 Git polling shouldnt need a workspace on a slave. We're seeing this message in (git) polling log, and we're using git plugin 1.1.23. Polling Log View as plain text This page captures the polling log that triggered this build. Started on Oct 15, 2012 11:24:38 PM Workspace is offline. Scheduling a new build to get a workspace. Done. Took 4 ms Changes found This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10131) Git polling shouldn't need a workspace on a slave.
Joe Hansche commented on JENKINS-10131 Git polling shouldnt need a workspace on a slave. Nicolas De Loof: What is the reason behind restricting the option to the simple case of single repo, single branch? git ls-remote can retrieve the full set of branches, and revisions for each, and then compare those branch revisions against the "last built revision" for each branch it is configured for. If any of them are different, then a build would be scheduled this is no different than what already happens with workspace polling, right? Another thing I don't understand, is how does it determine that it's not a single repo/single branch? That is, I'm using the multiple-scms plugin, and apparently that is causing the ls-remote option to be disabled automatically. But each instance of the GitSCM in my project contains only a single repo and a single branch, so why would that be failing? Multiple-SCMs should be able to isolate each of those separately, without considering it any more complex than a single repo, single branch. This behavior is a major problem for us, as we have the same problem that Christian reports in the first comment. We try to keep our master server free of builds, so that it can focus on its main task of "being the master." That means on restart, all of our jobs (well over 100) get scheduled immediately on startup, even though the slaves are actually coming online only seconds later. That is a huge waste of resources, and at times it actually causes the entire cluster to become unstable simply as a result of starting up! I'll look at modifying the ls-remote patch to see if I can get it to work with multiple branches, and also to find out why it behaves like this in the first place (since at least in my case, I actually don't have multiple branches). I just wanted to see if anyone else knows of some reason why what I said above could not work? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10131) Git polling shouldn't need a workspace on a slave.
Joe Hansche edited a comment on JENKINS-10131 Git polling shouldnt need a workspace on a slave. Nicolas De Loof: What is the reason behind restricting the option to the simple case of single repo, single branch? git ls-remote can retrieve the full set of branches, and revisions for each, and then compare those branch revisions against the "last built revision" for each branch it is configured for. If any of them are different, then a build would be scheduled this is no different than what already happens with workspace polling, right? Another thing I don't understand, is how does it determine that it's not a single repo/single branch? That is, I'm using the multiple-scms plugin, and apparently that is causing the ls-remote option to be disabled automatically. But each instance of the GitSCM in my project contains only a single repo and a single branch, so why would that be failing? Multiple-SCMs should be able to isolate each of those separately, without considering it any more complex than a single repo, single branch. This behavior is a major problem for us, as we have the same problem that Christian reports in the first comment. We try to keep our master server free of builds, so that it can focus on its main task of "being the master." That means on restart, all of our jobs (well over 100) get scheduled immediately on startup, even though the slaves are actually coming online only seconds later. That is a huge waste of resources, and at times it actually causes the entire cluster to become unstable simply as a result of starting up! I'll look at modifying the ls-remote patch to see if I can get it to work with multiple branches, and also to find out why it behaves like this in the first place (since at least in my case, I actually don't have multiple branches). I just wanted to see if anyone else knows of some reason why what I said above could not work? EDIT: bah, nevermind :/ I just realized what was causing it now... I was so focused on the "single branch" criteria, that I didn't think to look at excluded regions and users, which many of my projects use to prevent re-triggering a build when a Jenkins job is responsible for auto publishing commits (publishing things like minified _javascript_ and CSS, and newly compiled Flash (swf) files). Removed those exclusions, and it works. I agree with the other feature request though, that this should be caught via the frontend before the user even clicks save, so that at least he knows why it won't work. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
