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

Quiet period keeps running without building

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Component/s: other
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      We have upgraded from Hudson 1.224 to 1.244.
      We had projects set to a quiet period of 2 minutes. And we have svn update
      polling every minute.

      We kept this configuration, but this caused the builder not to build at all. It
      kept the job in the queue for every. It got reset every time (also without
      check-ins).
      We had to remove the quiet period to get it building.

        Attachments

          Issue Links

            Activity

            Hide
            dgreen dgreen added a comment -

            we have also experienced the same problem.

            Show
            dgreen dgreen added a comment - we have also experienced the same problem.
            Hide
            acronce acronce added a comment -

            I just ran into the same problem where we had our polling interval set to a minute, and a quiet period set
            to 10 minutes. This seems like a reasonable configuration, but builds are getting stuck.

            Show
            acronce acronce added a comment - I just ran into the same problem where we had our polling interval set to a minute, and a quiet period set to 10 minutes. This seems like a reasonable configuration, but builds are getting stuck.
            Hide
            dgreen dgreen added a comment -

            as a workaround what we've done is eliminate the quite period and set the polling interval to what was
            previously the quiet period. This doesn't have exactly the same effect, but for our purposes it has worked
            pretty well so far.

            Show
            dgreen dgreen added a comment - as a workaround what we've done is eliminate the quite period and set the polling interval to what was previously the quiet period. This doesn't have exactly the same effect, but for our purposes it has worked pretty well so far.
            Hide
            mindless Alan Harder added a comment -

            Copying my comment from related issue #2671:

            I can confirm this behavior. What's happening:

            In case of equal SCM-poll schedule and quiet period: initial quiet period ends
            and a build starts, and at the same time another SCM-poll starts. The SCM-poll
            thinks there are still new changes because it runs before the new build has a
            chance to update the job workspace with the latest changes from the repository.
            So that build runs AND a new one is scheduled (quiet period begins).

            Another variation: if the quiet period is slightly longer than the SCM poll
            schedule then a build never starts.. every SCM poll sees new changes and then
            extends the quiet period of the waiting job, so the quiet period never completes.

            WORKAROUND to avoid either issue: always keep quiet period at least 5-15 seconds
            shorter than any SCM-polling schedule/interval (however long SCM updates take).
            This gives the newly-started job time to update the job workspace before the
            next SCM poll.

            SOLUTION for these issues? Not sure.. perhaps some locking on the SCM-poll to
            prevent it from running if a build has started, but not yet updated the
            workspace. There's already some locking code around SCM-poll, so maybe it could
            be updated for this case.
            For the 2nd variation, there are a few options:

            • don't extend quiet period.. this would allow a build to start. easiest to
              implement; small change in Queue.add()
            • to keep extend-QP the SCM-poll would need some way to distinguish
              changes-vs-job-workspace from changes-since-last-poll, and only extend quiet
              period for the latter. not sure how this would work..
            Show
            mindless Alan Harder added a comment - Copying my comment from related issue #2671: I can confirm this behavior. What's happening: In case of equal SCM-poll schedule and quiet period: initial quiet period ends and a build starts, and at the same time another SCM-poll starts. The SCM-poll thinks there are still new changes because it runs before the new build has a chance to update the job workspace with the latest changes from the repository. So that build runs AND a new one is scheduled (quiet period begins). Another variation: if the quiet period is slightly longer than the SCM poll schedule then a build never starts.. every SCM poll sees new changes and then extends the quiet period of the waiting job, so the quiet period never completes. WORKAROUND to avoid either issue: always keep quiet period at least 5-15 seconds shorter than any SCM-polling schedule/interval (however long SCM updates take). This gives the newly-started job time to update the job workspace before the next SCM poll. SOLUTION for these issues? Not sure.. perhaps some locking on the SCM-poll to prevent it from running if a build has started, but not yet updated the workspace. There's already some locking code around SCM-poll, so maybe it could be updated for this case. For the 2nd variation, there are a few options: don't extend quiet period.. this would allow a build to start. easiest to implement; small change in Queue.add() to keep extend-QP the SCM-poll would need some way to distinguish changes-vs-job-workspace from changes-since-last-poll, and only extend quiet period for the latter. not sure how this would work..
            Hide
            mindless Alan Harder added a comment -
                • Issue 2382 has been marked as a duplicate of this issue. ***
            Show
            mindless Alan Harder added a comment - Issue 2382 has been marked as a duplicate of this issue. ***
            Hide
            mindless Alan Harder added a comment -
                • Issue 2626 has been marked as a duplicate of this issue. ***
            Show
            mindless Alan Harder added a comment - Issue 2626 has been marked as a duplicate of this issue. ***
            Hide
            mindless Alan Harder added a comment -
                • Issue 2530 has been marked as a duplicate of this issue. ***
            Show
            mindless Alan Harder added a comment - Issue 2530 has been marked as a duplicate of this issue. ***
            Hide
            mindless Alan Harder added a comment -
                • Issue 2416 has been marked as a duplicate of this issue. ***
            Show
            mindless Alan Harder added a comment - Issue 2416 has been marked as a duplicate of this issue. ***
            Hide
            mindless Alan Harder added a comment -
                • Issue 2240 has been marked as a duplicate of this issue. ***
            Show
            mindless Alan Harder added a comment - Issue 2240 has been marked as a duplicate of this issue. ***
            Hide
            aebbert aebbert added a comment -

            Going on cc: to track when this issue is fixed. Same problem for us. We used the
            quiet period to hold the Naginator Plugin from building every 5 seconds, but we
            have to disable Naginator and quiet period for now.

            Show
            aebbert aebbert added a comment - Going on cc: to track when this issue is fixed. Same problem for us. We used the quiet period to hold the Naginator Plugin from building every 5 seconds, but we have to disable Naginator and quiet period for now.
            Hide
            maxence maxence added a comment -

            Ran through the same issue, I had the quiet period set to 5 minutes and my jobs
            weren't building after a SCM change. Set the quiet period to 0 and jobs started
            building.

            It seems that the quiet period feature is not really working as it is, or at
            least confusing without further explanation.

            Until a fix is found (I understand it's not trivial), wouldn't be a good idea to
            remove this feature from the web UI, or at least to put a warning in the help
            tooltip ?

            This is the only issue that prevented Hudson from working out-of-the-box for me,
            and I believe many users have or will bump into the same issue.

            PS: great job guys, I'm really impressed!

            Show
            maxence maxence added a comment - Ran through the same issue, I had the quiet period set to 5 minutes and my jobs weren't building after a SCM change. Set the quiet period to 0 and jobs started building. It seems that the quiet period feature is not really working as it is, or at least confusing without further explanation. Until a fix is found (I understand it's not trivial), wouldn't be a good idea to remove this feature from the web UI, or at least to put a warning in the help tooltip ? This is the only issue that prevented Hudson from working out-of-the-box for me, and I believe many users have or will bump into the same issue. PS: great job guys, I'm really impressed!
            Hide
            mcpdr mcpdr added a comment -

            added myself to the cc for this issue.

            Any idea when this issue might be fixed? This is the only issue we have had
            with Hudson. We are trying to manage multiple interdependant projects, which
            is difficult with this issue. It causes many false broken build messages, as
            it starts the build before the proper time, particularly on large, multi-step
            checkins.

            Show
            mcpdr mcpdr added a comment - added myself to the cc for this issue. Any idea when this issue might be fixed? This is the only issue we have had with Hudson. We are trying to manage multiple interdependant projects, which is difficult with this issue. It causes many false broken build messages, as it starts the build before the proper time, particularly on large, multi-step checkins.
            Hide
            mindless Alan Harder added a comment -

            first comment: if having a quiet period would be helpful but you've hit this
            issue, consider raising your SCM polling interval rather than lowering or
            removing the quiet period. for example, if you need a 10 minute quiet period
            then set your SCM polling interval to 15 minutes.

            second comment: would anyone object to never extending the quiet period? ie, if
            your QP is 10 minutes and a build is triggered then it will start in 10 minutes,
            even if new SCM changes come in during that time. The reason this issue is not
            fixed yet is that it is very non-trivial to determine if a detected SCM change
            is new vs the workspace or new vs the last poll, and would likely require coding
            for each SCM system. It is far, far easier to simply not extend the QP when a
            build is re-triggered. Please comment whether this sounds acceptable, or
            explain your use case where extending the QP is important (I can see it being
            convenient if you checkin several things in sequence, but if that is common you
            can just set the QP to 15-30 minutes or something).

            Show
            mindless Alan Harder added a comment - first comment: if having a quiet period would be helpful but you've hit this issue, consider raising your SCM polling interval rather than lowering or removing the quiet period. for example, if you need a 10 minute quiet period then set your SCM polling interval to 15 minutes. second comment: would anyone object to never extending the quiet period? ie, if your QP is 10 minutes and a build is triggered then it will start in 10 minutes, even if new SCM changes come in during that time. The reason this issue is not fixed yet is that it is very non-trivial to determine if a detected SCM change is new vs the workspace or new vs the last poll, and would likely require coding for each SCM system. It is far, far easier to simply not extend the QP when a build is re-triggered. Please comment whether this sounds acceptable, or explain your use case where extending the QP is important (I can see it being convenient if you checkin several things in sequence, but if that is common you can just set the QP to 15-30 minutes or something).
            Hide
            jdruce jdruce added a comment -

            When we set the quiet period to 5 minutes and the polling to 6 minutes, it does
            not detect any checkins done inside the 5 minute quiet period. I would assume
            that as soon as something is checked in inside the quiet period that the
            counter would reset to 5 minutes again. It appears this is not happening.

            Show
            jdruce jdruce added a comment - When we set the quiet period to 5 minutes and the polling to 6 minutes, it does not detect any checkins done inside the 5 minute quiet period. I would assume that as soon as something is checked in inside the quiet period that the counter would reset to 5 minutes again. It appears this is not happening.
            Hide
            mindless Alan Harder added a comment -

            @jdruce: that's right.. please see "second comment" above. It is not easy to
            detect more checkins during the quiet period. Right now it can't distinguish
            the original checkin from an additional one, so if your poll interval is < quiet
            period then it keeps extending the QP forever. I'm recommending never extending
            the QP, so a build will always start after N minutes regardless of whether your
            QP is shorter or longer than the SCM poll interval.

            Show
            mindless Alan Harder added a comment - @jdruce: that's right.. please see "second comment" above. It is not easy to detect more checkins during the quiet period. Right now it can't distinguish the original checkin from an additional one, so if your poll interval is < quiet period then it keeps extending the QP forever. I'm recommending never extending the QP, so a build will always start after N minutes regardless of whether your QP is shorter or longer than the SCM poll interval.
            Hide
            gj gj added a comment -

            just adding myself to the cc list

            Show
            gj gj added a comment - just adding myself to the cc list
            Hide
            mdonohue mdonohue added a comment -

            This issue appears to be the flipside of issue 1737.

            The suggestion from June 6 would be to revert the behavior thats in Hudson now.
            I think we can provide a more fine-grained approach, by adding a method like
            'supportsIncrementalPolling' to hudson.scm.SCM, which would default to false -
            matching what most SCM plugins do today. If a SCM can do polling from the
            last poll, instead of from the last build, it would return 'true' for
            incremental polling.

            When incremental polling is available for an SCM, the quiet period would work as
            specified in issue 1737. When incremental polling is not available, the quiet
            period would just become a build delay.

            Show
            mdonohue mdonohue added a comment - This issue appears to be the flipside of issue 1737. The suggestion from June 6 would be to revert the behavior thats in Hudson now. I think we can provide a more fine-grained approach, by adding a method like 'supportsIncrementalPolling' to hudson.scm.SCM, which would default to false - matching what most SCM plugins do today. If a SCM can do polling from the last poll, instead of from the last build, it would return 'true' for incremental polling. When incremental polling is available for an SCM, the quiet period would work as specified in issue 1737. When incremental polling is not available, the quiet period would just become a build delay.
            Hide
            dominikg dominikg added a comment -

            just ran into this on hudson 1.334 the other day and would like to see it fixed.

            Another possible workaround for svn users could be to use a polling frequency of
            @yearly and setup a post-commit hook to notify hudson[1]. That way, quiet period
            should only be extended if a new commit happens.

            regards,
            Dominik

            [1] http://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin

            Show
            dominikg dominikg added a comment - just ran into this on hudson 1.334 the other day and would like to see it fixed. Another possible workaround for svn users could be to use a polling frequency of @yearly and setup a post-commit hook to notify hudson [1] . That way, quiet period should only be extended if a new commit happens. regards, Dominik [1] http://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in hudson
            User: : kohsuke
            Path:
            http://fisheye4.cenqua.com/changelog/hudson/?cs=24266
            Log:
            Creating a branch to play with a possible fix for JENKINS-2180.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: http://fisheye4.cenqua.com/changelog/hudson/?cs=24266 Log: Creating a branch to play with a possible fix for JENKINS-2180 .
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in hudson
            User: : kohsuke
            Path:
            http://fisheye4.cenqua.com/changelog/hudson/?cs=24270
            Log:
            Branching the subversion plugin to make sure the fix for JENKINS-2180 works with a real-world SCM.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: http://fisheye4.cenqua.com/changelog/hudson/?cs=24270 Log: Branching the subversion plugin to make sure the fix for JENKINS-2180 works with a real-world SCM.
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            Proposed change implemented and subversion/mercurial plugins are branched out to test this.

            Remaining work:

            • Look at test failures
            • Add a few more tests to verify the behavior
            • merge and release
            Show
            kohsuke Kohsuke Kawaguchi added a comment - Proposed change implemented and subversion/mercurial plugins are branched out to test this. Remaining work: Look at test failures Add a few more tests to verify the behavior merge and release
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in hudson
            User: : kohsuke
            Path:
            http://jenkins-ci.org/commit/27086
            Log:
            Initialized merge tracking via "svnmerge" with revisions "1-27085" from
            https://www.dev.java.net/svn/hudson/branches/JENKINS-2180

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: http://jenkins-ci.org/commit/27086 Log: Initialized merge tracking via "svnmerge" with revisions "1-27085" from https://www.dev.java.net/svn/hudson/branches/JENKINS-2180
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in hudson
            User: : kohsuke
            Path:
            http://jenkins-ci.org/commit/27088
            Log:
            Initialized merge tracking via "svnmerge" with revisions "1-24268" from
            https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/main

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: http://jenkins-ci.org/commit/27088 Log: Initialized merge tracking via "svnmerge" with revisions "1-24268" from https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/main
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in hudson
            User: : kohsuke
            Path:
            trunk/hudson/main/core/src/main/java/hudson/fsp/WorkspaceSnapshotSCM.java
            trunk/hudson/main/core/src/main/java/hudson/model/AbstractProject.java
            trunk/hudson/main/core/src/main/java/hudson/scm/NullSCM.java
            trunk/hudson/main/core/src/main/java/hudson/scm/SCM.java
            trunk/hudson/main/test/src/test/groovy/hudson/cli/BuildCommandTest.groovy
            trunk/www/changelog.html
            http://jenkins-ci.org/commit/27103
            Log:
            [FIXED JENKINS-2180] revised the design of polling to fix the problem.
            See:

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/hudson/main/core/src/main/java/hudson/fsp/WorkspaceSnapshotSCM.java trunk/hudson/main/core/src/main/java/hudson/model/AbstractProject.java trunk/hudson/main/core/src/main/java/hudson/scm/NullSCM.java trunk/hudson/main/core/src/main/java/hudson/scm/SCM.java trunk/hudson/main/test/src/test/groovy/hudson/cli/BuildCommandTest.groovy trunk/www/changelog.html http://jenkins-ci.org/commit/27103 Log: [FIXED JENKINS-2180] revised the design of polling to fix the problem. See:
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in hudson
            User: : kohsuke
            Path:
            http://jenkins-ci.org/commit/27142
            Log:
            Initialized merge tracking via "svnmerge" with revisions "1-24270" from
            https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/subversion

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: http://jenkins-ci.org/commit/27142 Log: Initialized merge tracking via "svnmerge" with revisions "1-24270" from https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/subversion
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in hudson
            User: : kohsuke
            Path:
            trunk/hudson/plugins/mercurial/pom.xml
            trunk/hudson/plugins/mercurial/src/main/java/hudson/plugins/mercurial/MercurialSCM.java
            trunk/hudson/plugins/mercurial/src/main/java/hudson/plugins/mercurial/MercurialTagAction.java
            http://jenkins-ci.org/commit/27484
            Log:
            Merged revisions 27063,27067 via svnmerge from
            https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/mercurial

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/hudson/plugins/mercurial/pom.xml trunk/hudson/plugins/mercurial/src/main/java/hudson/plugins/mercurial/MercurialSCM.java trunk/hudson/plugins/mercurial/src/main/java/hudson/plugins/mercurial/MercurialTagAction.java http://jenkins-ci.org/commit/27484 Log: Merged revisions 27063,27067 via svnmerge from https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/mercurial
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in hudson
            User: : kohsuke
            Path:
            http://jenkins-ci.org/commit/27483
            Log:
            Initialized merge tracking via "svnmerge" with revisions "1-27061" from
            https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/mercurial

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: http://jenkins-ci.org/commit/27483 Log: Initialized merge tracking via "svnmerge" with revisions "1-27061" from https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/mercurial
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in hudson
            User: : kohsuke
            Path:
            trunk/hudson/plugins/subversion/pom.xml
            trunk/hudson/plugins/subversion/src/main/java/hudson/scm/SubversionSCM.java
            trunk/hudson/plugins/subversion/src/test/java/hudson/scm/SubversionSCMTest.java
            http://jenkins-ci.org/commit/27482
            Log:
            Merged revisions 24271,27060,27064 via svnmerge from
            https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/subversion

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/hudson/plugins/subversion/pom.xml trunk/hudson/plugins/subversion/src/main/java/hudson/scm/SubversionSCM.java trunk/hudson/plugins/subversion/src/test/java/hudson/scm/SubversionSCMTest.java http://jenkins-ci.org/commit/27482 Log: Merged revisions 24271,27060,27064 via svnmerge from https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/subversion
            Hide
            adrian_ adrian_ added a comment - - edited

            As of the 1.346 release notes this should be resolved, but isn't.

            It's still the same behavior as before. The period is reseted after each svn check, even if there where no changes.

            Show
            adrian_ adrian_ added a comment - - edited As of the 1.346 release notes this should be resolved, but isn't. It's still the same behavior as before. The period is reseted after each svn check, even if there where no changes.
            Hide
            mindless Alan Harder added a comment -

            I also thought this was a bit premature to go in the changelog.. the core support was added, but SCM plugins must then be updated to use it. So you need 1.346+ and the next release of Subversion plugin (I don't know the ETA on that).

            Show
            mindless Alan Harder added a comment - I also thought this was a bit premature to go in the changelog.. the core support was added, but SCM plugins must then be updated to use it. So you need 1.346+ and the next release of Subversion plugin (I don't know the ETA on that).
            Hide
            mdonohue mdonohue added a comment -

            > If this should be the expected behavior I don't know what's this feature good for.

            I find this comment to be entirely antagonistic for no reason. Some humility when asking for help goes a long way.

            Show
            mdonohue mdonohue added a comment - > If this should be the expected behavior I don't know what's this feature good for. I find this comment to be entirely antagonistic for no reason. Some humility when asking for help goes a long way.
            Hide
            adrian_ adrian_ added a comment -

            @mdonohue

            You are right. I removed it.

            Show
            adrian_ adrian_ added a comment - @mdonohue You are right. I removed it.
            Hide
            mindless Alan Harder added a comment -

            Marking as resolved again, now that subversion plugin 1.12 has been released.

            Show
            mindless Alan Harder added a comment - Marking as resolved again, now that subversion plugin 1.12 has been released.
            Hide
            ganncamp G. Ann Campbell added a comment -

            I'm seeing this issue - or something very like it with CVS on Jenkins version 1.414, CVS Plugin 1.4

            I had polling turned on in my CI projects but with a blank poll schedule. I wanted to enable polling but not actually do it. Once I realized what was going on, I set the polling schedule to once a day but still saw this behavior. Even tried restarting Jenkins in the hopes that it would clear any cobwebs or old polling threads with a bad schedule, but still saw the behavior.
            It didn't resolve until I disabled polling altogether.

            Show
            ganncamp G. Ann Campbell added a comment - I'm seeing this issue - or something very like it with CVS on Jenkins version 1.414, CVS Plugin 1.4 I had polling turned on in my CI projects but with a blank poll schedule. I wanted to enable polling but not actually do it. Once I realized what was going on, I set the polling schedule to once a day but still saw this behavior. Even tried restarting Jenkins in the hopes that it would clear any cobwebs or old polling threads with a bad schedule, but still saw the behavior. It didn't resolve until I disabled polling altogether.
            Hide
            ganncamp G. Ann Campbell added a comment -

            Sorry if you get this twice - I just posted to the issue before re-opening. I am seeing this behavior on Jenkins 1.414 & CVS plugin 1.4.

            I merely had polling enabled in the CI jobs, but with no schedule & a 5-min. quiet period. Jobs would tick down the quiet period to just under a minute, then reset. Checking the access logs showed no additional CI triggers.

            Setting a daily poll cron still didn't help. I finally disabled polling altogether & finally saw jobs finishing their quiet periods and building.

            I'll be happy to provide whatever system information you need.

            Show
            ganncamp G. Ann Campbell added a comment - Sorry if you get this twice - I just posted to the issue before re-opening. I am seeing this behavior on Jenkins 1.414 & CVS plugin 1.4. I merely had polling enabled in the CI jobs, but with no schedule & a 5-min. quiet period. Jobs would tick down the quiet period to just under a minute, then reset. Checking the access logs showed no additional CI triggers. Setting a daily poll cron still didn't help. I finally disabled polling altogether & finally saw jobs finishing their quiet periods and building. I'll be happy to provide whatever system information you need.
            Hide
            mindless Alan Harder added a comment -

            This was a long running issue and I'd rather not see it reopened. I believe the problem is the newer polling API was implemented for subversion plugin but probably not for CVS. Please file a new feature request asking for new polling API support in CVS plugin, thanks!

            Show
            mindless Alan Harder added a comment - This was a long running issue and I'd rather not see it reopened. I believe the problem is the newer polling API was implemented for subversion plugin but probably not for CVS. Please file a new feature request asking for new polling API support in CVS plugin, thanks!
            Hide
            mineralwasser Patric Rufflar added a comment -

            I'm still seeing this issue using Jenkins 1.596.2 and Subversion plugin 2.5.
            Quiet period is set to 900 seconds, SCM polling is done every minute.
            Jenkins is always showing "(pending—In the quiet period. Expires in 14 min)".

            Am I doing something wrong?

            Show
            mineralwasser Patric Rufflar added a comment - I'm still seeing this issue using Jenkins 1.596.2 and Subversion plugin 2.5. Quiet period is set to 900 seconds, SCM polling is done every minute. Jenkins is always showing "(pending—In the quiet period. Expires in 14 min)". Am I doing something wrong?
            Hide
            danielbeck Daniel Beck added a comment -

            Patric Rufflar:

            Am I doing something wrong?

            I see the same issue (on 1.565.3 as well). Please file a new issue about this against the core component and assign it to me, I'll look into it.

            Show
            danielbeck Daniel Beck added a comment - Patric Rufflar : Am I doing something wrong? I see the same issue (on 1.565.3 as well). Please file a new issue about this against the core component and assign it to me, I'll look into it.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Daniel Beck
            Path:
            core/src/main/java/hudson/model/Queue.java
            http://jenkins-ci.org/commit/jenkins/1072f5c1372d2884beb07c9114b9b90ce0bf037e
            Log:
            JENKINS-2180 Always use earlier scheduling date.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Daniel Beck Path: core/src/main/java/hudson/model/Queue.java http://jenkins-ci.org/commit/jenkins/1072f5c1372d2884beb07c9114b9b90ce0bf037e Log: JENKINS-2180 Always use earlier scheduling date.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Daniel Beck
            Path:
            core/src/main/java/hudson/model/Queue.java
            http://jenkins-ci.org/commit/jenkins/c9c62d3681460d4898f26e8fe07b9d4fc80f40e7
            Log:
            Merge pull request #1665 from daniel-beck/JENKINS-2180

            JENKINS-2180 Always use earlier scheduling date.

            Compare: https://github.com/jenkinsci/jenkins/compare/8c5b9cd008a4...c9c62d368146

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Daniel Beck Path: core/src/main/java/hudson/model/Queue.java http://jenkins-ci.org/commit/jenkins/c9c62d3681460d4898f26e8fe07b9d4fc80f40e7 Log: Merge pull request #1665 from daniel-beck/ JENKINS-2180 JENKINS-2180 Always use earlier scheduling date. Compare: https://github.com/jenkinsci/jenkins/compare/8c5b9cd008a4...c9c62d368146
            Hide
            dogfood dogfood added a comment -

            Integrated in jenkins_main_trunk #4189
            JENKINS-2180 Always use earlier scheduling date. (Revision 1072f5c1372d2884beb07c9114b9b90ce0bf037e)

            Result = UNSTABLE
            daniel-beck : 1072f5c1372d2884beb07c9114b9b90ce0bf037e
            Files :

            • core/src/main/java/hudson/model/Queue.java
            Show
            dogfood dogfood added a comment - Integrated in jenkins_main_trunk #4189 JENKINS-2180 Always use earlier scheduling date. (Revision 1072f5c1372d2884beb07c9114b9b90ce0bf037e) Result = UNSTABLE daniel-beck : 1072f5c1372d2884beb07c9114b9b90ce0bf037e Files : core/src/main/java/hudson/model/Queue.java

              People

              • Assignee:
                kohsuke Kohsuke Kawaguchi
                Reporter:
                cbos Cees Bos
              • Votes:
                19 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: