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