-
Bug
-
Resolution: Fixed
-
Critical
-
None
-
Platform: All, OS: All
I guess the issue I'm reporting is loosly related to issues 688 & 692.
Config :-
---------
1) Using Hudson 1.262 on Solaris 10 machine.
Settings for project
--------------------
1) SVN Polled every 5 mintutes
2) Quiteperiod set to 5 minutes
Sequence of Steps :-
--------------------
1) Check-in Test1.properties at 10:00 AM
Hudson deducts changes on SVN and waits for the quite period (5 mins).
2) Check-in Test2.properties at 10:02 AM
After the first quite period, Hudson deducts another change on SVN and waits
again for quite period (5 mins)
3) After the second quite period, Hudson starts the build for the changes.
4) Hudson also STARTS ANOTHER BUILD even though there are no more changes on
SVN. The console output also shows that NO CHANGES were deducted since the
previous build.
Thanks
Bharath
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:
implement; small change in Queue.add()
changes-vs-job-workspace from changes-since-last-poll, and only extend quiet
period for the latter. not sure how this would work..