[JIRA] (JENKINS-10131) Git polling shouldn't need a workspace on a slave.

[jhans...@myyearbook.com (JIRA)]

Joe Hansche commented on JENKINS-10131 Git polling shouldn't 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