we have also experienced the same problem.

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.

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.

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

• • • Issue 2382 has been marked as a duplicate of this issue. ***

• • • Issue 2626 has been marked as a duplicate of this issue. ***

• • • Issue 2530 has been marked as a duplicate of this issue. ***

• • • Issue 2416 has been marked as a duplicate of this issue. ***

• • • Issue 2240 has been marked as a duplicate of this issue. ***

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.

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!

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.

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

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.

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

just adding myself to the cc list

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.

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

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.

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.

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

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

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

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:

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

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

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

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

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.

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

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

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

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.

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.

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!

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?

mineralwasser:

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.

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.

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

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