[JENKINS-1348] "Workspace is offline" triggers a build

Last Subversion Polling Log

Started on Feb 29, 2008 9:01:22 AM
Workspace is offline.
Done. Took 0 seconds
Changes found

This job is tied to a slave node which is offline right now. The above polling
log shows "changes found" at the end, and a build was triggered (which is now
waiting for the slave node to come back online).
There have not been any changes in the repository, so I don't think this case
should trigger a build.

Originally reported by mindless, imported from: "Workspace is offline" triggers a build

status: Closed
priority: Major
component(s): remoting
resolution: Fixed
resolved: 2008-03-14T00:06:17+00:00
votes: 0
watchers: 6
imported: 2025-11-25

Raw content of original issue

Last Subversion Polling Log

Started on Feb 29, 2008 9:01:22 AM Workspace is offline. Done. Took 0 seconds Changes found

This job is tied to a slave node which is offline right now. The above polling log shows "changes found" at the end, and a build was triggered (which is now waiting for the slave node to come back online). There have not been any changes in the repository, so I don't think this case should trigger a build.

environment: Platform: All, OS: All

1 attachment

issue1348.patch.txt

kohsuke:

Original comment link

Raw content of original comment:

This is actually by design.

The polling always require a valid workspace — you compare what's in the repository with what we have locally, and decide if we need another build.

So when we lose a workspace, we need to trigger a build so that we can get a new workspace, and only then we can resume polling.

If this condition won't trigger a polling, nothing will ever gets built.

This is actually by design.

The polling always require a valid workspace — you compare what's in the
repository with what we have locally, and decide if we need another build.

So when we lose a workspace, we need to trigger a build so that we can get a new
workspace, and only then we can resume polling.

If this condition won't trigger a polling, nothing will ever gets built.

huybrechts:

Original comment link

Raw content of original comment:

I disagree. Not all SCM systems require a workspace for polling. E.g. SVN does not. This is issue is causing builds that only run on one particular slave to be automatically scheduled when the slave goes offline.

Attaching a patch that takes care of this for SVN.

ps: we talked about this here: http://www.nabble.com/builds-scheduled-when-slave-goes-offline-to14970461.html#a14970461

I disagree. Not all SCM systems require a workspace for polling. E.g. SVN does
not. This is issue is causing builds that only run on one particular slave to be
automatically scheduled when the slave goes offline.

Attaching a patch that takes care of this for SVN.

ps: we talked about this here:
http://www.nabble.com/builds-scheduled-when-slave-goes-offline-to14970461.html#a14970461

huybrechts:

Original comment link
Raw content of original comment:
```
Created an attachment (id=183)
patch
```

Created an attachment (id=183)
patch

mindless:

Original comment link

Raw content of original comment:

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.

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.

kohsuke:

Original comment link

Raw content of original comment:

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)

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)

mindless:

Original comment link

Raw content of original comment:

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.

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.

kohsuke:

Original comment link
Raw content of original comment:
```
Fixed in 1.196.
```

Fixed in 1.196.

paulmoran:

Original comment link

Raw content of original comment:

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

mindless:

Original comment link

Raw content of original comment:

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~~.

brian:

Original comment link

Raw content of original comment:

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?

jhansche:

Original comment link

Raw content of original comment:

@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.

@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.

marc_guenther:

Original comment link

Raw content of original comment:

@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.

The reason for this is mentioned in the help section:

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!

@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.

The reason for this is mentioned in the help section:

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!

Navigation Menu

Repository navigation

[JENKINS-1348] "Workspace is offline" triggers a build #874

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[JENKINS-1348] "Workspace is offline" triggers a build #874

Description

Activity

jenkins-infra-bot commented on Feb 29, 2008

jenkins-infra-bot commented on Mar 1, 2008

jenkins-infra-bot commented on Mar 1, 2008

jenkins-infra-bot commented on Mar 3, 2008

jenkins-infra-bot commented on Mar 3, 2008

jenkins-infra-bot commented on Mar 3, 2008

jenkins-infra-bot commented on Mar 14, 2008

jenkins-infra-bot commented on Nov 26, 2010

jenkins-infra-bot commented on Dec 27, 2010

jenkins-infra-bot commented on Feb 17, 2012

jenkins-infra-bot commented on Sep 13, 2012

jenkins-infra-bot commented on Nov 1, 2013

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions