Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-1348

"Workspace is offline" triggers a build

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: remoting
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      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.

        Attachments

          Activity

          Hide
          paulmoran paulmoran added a comment -

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

          Show
          paulmoran paulmoran added a comment - Hi I'm pretty sure this is exactly the same as JENKINS-8173 , will this patch work for Perforce too?
          Hide
          mindless Alan Harder added a 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.

          Show
          mindless Alan Harder added a 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 .
          Hide
          brian Brian Murrell added a 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?

          Show
          brian Brian Murrell added a 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?
          Hide
          jhansche Joe Hansche added a 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.

          Show
          jhansche Joe Hansche added a 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.
          Hide
          marc_guenther Marc Günther added a 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!

          Show
          marc_guenther Marc Günther added a 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!

            People

            • Assignee:
              Unassigned
              Reporter:
              mindless Alan Harder
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: