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

Sync mechanism between SCM polling and node availability

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • accurev-plugin
    • None
    • Master: Win Server 2003 R2 x64, jdk1.6.0_20_x64; Slaves: Win Server 2003 R2 x64, Win Server 2008 R2 x64, jdk1.6.0_20_x64; Hudson 1.377

      If the slave availability is set to "Take this slave on-line when in demand and off-line when idle" then it happens quite often that the SCM polling won't find the workspace on the slave. This leads the polling to assume there are changes and therefore it triggers a new build due to the active "Poll SCM" setting even though there are no changes in the SCM. That means in our case this job is constantly building.

      Is there a way that the SCM polling only happens when the slave is awake or that the SCM polling wakes up the slave?

          [JENKINS-8053] Sync mechanism between SCM polling and node availability

          paulmoran added a comment -

          Hi I think this is the same issue as JENKINS-8173?

          paulmoran added a comment - Hi I think this is the same issue as JENKINS-8173 ?

          robsimon added a comment -

          Hi,

          we don't use the Perforce plugin for polling.

          In our case the Accurev polling is looking for the Hudson workspace to perform "accurev info", "accurev show" and "accurev hist". Based on this it figures that if there are changes to kick off a new build or not.

          However, if there is no Hudson workspace available then it kicks off a build to create one to be able to make steps above the next time. That means every time when the node is offline a new build is triggered without having the need for it.

          Nevertheless, we do not understand why there is a Hudson workspace needed for the polling steps which are going against the SCM.

          Robert

          robsimon added a comment - Hi, we don't use the Perforce plugin for polling. In our case the Accurev polling is looking for the Hudson workspace to perform "accurev info", "accurev show" and "accurev hist". Based on this it figures that if there are changes to kick off a new build or not. However, if there is no Hudson workspace available then it kicks off a build to create one to be able to make steps above the next time. That means every time when the node is offline a new build is triggered without having the need for it. Nevertheless, we do not understand why there is a Hudson workspace needed for the polling steps which are going against the SCM. Robert

          Code changed in jenkins
          User: Mark Waite
          Path:
          src/test/java/org/jenkinsci/plugins/gitclient/GitAPITestCase.java
          http://jenkins-ci.org/commit/git-client-plugin/eec1a16bc7ddff1ffd022f5c9e5f631f1a63f329
          Log:
          Add two detailed submodule tests

          Tests describe the implementation as it currently exists, in hopes
          of detecting future regressions with test execution. The tests show
          inconsistencies between the CliGitAPIImpl and JGitAPIImpl classes,
          and inconsistencies between command line git and JGit behavior.

          Command line git clean as implemented in CliGitAPIImpl does not remove
          untracked submodules or files contained in untracked submodule dirs.
          JGit clean as implemented in JGitAPIImpl removes untracked submodules.
          This test captures that surprising difference between the implementations.

          CliGitAPIImpl supports renamed submodules. JGitAPIImpl does not support
          renamed submodules. One of these tests captures that difference.

          See bug reports such as:
          JENKINS-22510 - Clean After Checkout Results in Failed to Checkout Revision
          JENKINS-8053 - Git submodules are cloned too early and not removed once the revToBuild has been checked out
          JENKINS-14083 - Build can't recover from broken submodule path
          JENKINS-15399 - Changing remote URL doesn't update submodules

          Compare: https://github.com/jenkinsci/git-client-plugin/compare/cdcbfd56f49f...eec1a16bc7dd

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: src/test/java/org/jenkinsci/plugins/gitclient/GitAPITestCase.java http://jenkins-ci.org/commit/git-client-plugin/eec1a16bc7ddff1ffd022f5c9e5f631f1a63f329 Log: Add two detailed submodule tests Tests describe the implementation as it currently exists, in hopes of detecting future regressions with test execution. The tests show inconsistencies between the CliGitAPIImpl and JGitAPIImpl classes, and inconsistencies between command line git and JGit behavior. Command line git clean as implemented in CliGitAPIImpl does not remove untracked submodules or files contained in untracked submodule dirs. JGit clean as implemented in JGitAPIImpl removes untracked submodules. This test captures that surprising difference between the implementations. CliGitAPIImpl supports renamed submodules. JGitAPIImpl does not support renamed submodules. One of these tests captures that difference. See bug reports such as: JENKINS-22510 - Clean After Checkout Results in Failed to Checkout Revision JENKINS-8053 - Git submodules are cloned too early and not removed once the revToBuild has been checked out JENKINS-14083 - Build can't recover from broken submodule path JENKINS-15399 - Changing remote URL doesn't update submodules Compare: https://github.com/jenkinsci/git-client-plugin/compare/cdcbfd56f49f...eec1a16bc7dd

            statler Scott Tatum
            robsimon robsimon
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: