Created an attachment (id=183)
patch

I agree a lost workspace may have to trigger a build sometimes, but I don't
agree it applies to this case, regardless of whether the SCM is svn..
The workspace is not lost. Once the slave node comes back online the workspace
is still there, and normal polling can resume. Then it can find out the
workspace is still up to date.. no build needed.

Hmm, good point about Subversion. We should apply your patch.

mindless, what if we add some heuristics — for example, it should hold off a
build if the job is tied to a particular slave and that is offline, and maybe
Hudson should wait for let's say an hour before attempting to schedule a new
build (hoping that within the said hour maybe the offline slave comes back)

well, since I happen to be using subversion I guess that patch will resolve the
problem for me. But in general, if a project is tied to a particular slave node
then I don't see the point of triggering a build.. the build can't run until the
slave node comes back online anyway. So in this case it seems like it could
wait indefinitely... if the job can run on several different slave nodes but the
one with the workspace happens to be offline then I'm not sure the best
behavior.. waiting some time before triggering a new build (on another slave
node) sounds ok.

Fixed in 1.196.

Hi I'm pretty sure this is exactly the same as JENKINS-8173, will this patch work for Perforce too?

PaulMoran, the change made in this issue was in core so it affects perforce too.. AbstractProject's polling method won't launch a new build for workspace offline if the SCM returns false for requiresWorkspaceForPolling. This method for subversion simply returns false.. however, I see in perforce code it is dynamic ("isSlaveClientNameStatic()") so this patch affects perforce "sometimes".. presumably that is what the discussion is about in JENKINS-8173.

I don't really know how polling for git works but I wonder if this same issue applies to git. i.e. does it actually need a workspace to poll or is it like subversion and not need one?

@Brian: The git plugin does support a "fast remote polling", using the git ls-remote command, which allows fetching the latest revisions from the remote URL without actually requiring a workspace to keep an entire clone of the repository. That then only requires that the git plugin keep track of the last built revisions, and if the revision doesn't match, it would trigger a new build.

That said, the git plugin currently does not appear to save this option properly, as every time I check that box, it appears to get lost the next time I look at the configuration.

The really annoying part of this behavior is that the SCM poller is already starting to do work before the slaves even have a chance to come online (for persistent slaves). So pretty much every restart of Jenkins in my experience, causes all SCM polling jobs to schedule new builds, even though nothing changed and there's no reason to start a build. That has the downside that all my slaves are hosed for at least 5-10 minutes after a startup.

To make matters worse, using the "Purge Build Queue" plugin to clear out the build queue on startup, actually does more harm than good, because it appears to leave the SCM pollers in an unstable state, and eventually one or more slaves seems to become unresponsive, and it's just a cascading effect from there.

@Joe:

That said, the git plugin currently does not appear to save this option properly, as every time I check that box, it appears to get lost the next time I look at the configuration.

If you want to use this, you can have only one repository with one branch (no wildcards!), and you can not use any excluded regions, excluded users or submodules, otherwise this option will disable itself after save.

It is still stupid behaviour, though (also see JENKINS-10131)

BTW, why is this issue closed? "Workspace is offline" still triggers unwanted builds, afaik, and we have 2013 now!