[JENKINS-2180] Quiet period keeps running without building

[jenkins-infra-bot]

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.

---

Originally reported by cbos, imported from: Quiet period keeps running without building

• assignee: kohsuke
• status: Closed
• priority: Major
• component(s): other
• resolution: Fixed
• resolved: 2011-07-05T23:28:36+00:00
• votes: 19
• watchers: 10
• imported: 2025-12-08

Raw content of original issue

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.

• environment: Platform: All, OS: All

[jenkins-infra-bot]

dgreen:

• Original comment link
• Raw content of original comment:

  we have also experienced the same problem.
  

we have also experienced the same problem.

[jenkins-infra-bot]

acronce:

• Original comment link
• Raw content of original 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.
  

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.

[jenkins-infra-bot]

dgreen:

• Original comment link
• Raw content of original 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.
  

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.

[jenkins-infra-bot]

mindless:

• Original comment link
• Raw content of original 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..
  
  
  

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

[jenkins-infra-bot]

mindless:

• Original comment link
• Raw content of original comment:

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

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

[jenkins-infra-bot]

mindless:

• Original comment link
• Raw content of original comment:

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

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

[jenkins-infra-bot]

mindless:

• Original comment link
• Raw content of original comment:

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

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

[jenkins-infra-bot]

mindless:

• Original comment link
• Raw content of original comment:

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

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

[jenkins-infra-bot]

mindless:

• Original comment link
• Raw content of original comment:

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

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

[jenkins-infra-bot]

aebbert:

• Original comment link
• Raw content of original 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.
  

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.

[jenkins-infra-bot]

maxence:

• Original comment link
• Raw content of original 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!
  

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!

[jenkins-infra-bot]

mcpdr:

• Original comment link
• Raw content of original 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.
  

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.

[jenkins-infra-bot]

mindless:

• Original comment link
• Raw content of original 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).
  

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

[jenkins-infra-bot]

jdruce:

• Original comment link
• Raw content of original 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.
  

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.

[jenkins-infra-bot]

mindless:

• Original comment link
• Raw content of original 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.
  

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