• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • subversion-plugin
    • 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

          [JENKINS-2671] Extra build triggered with no changes

          Alan Harder added a comment -

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

          Alan Harder added a comment - 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..

          Alan Harder added a comment -

          Looked into this a bit.. my approach was to use ResourceController so poll won't
          run at the same time as checkout/update. Wrapping code in Runnables is a little
          ugly, but this does work (unit test included; also tested in UI). Feedback
          appreciated on whether to commit this, or recommendation for alternate approach.

          Alan Harder added a comment - Looked into this a bit.. my approach was to use ResourceController so poll won't run at the same time as checkout/update. Wrapping code in Runnables is a little ugly, but this does work (unit test included; also tested in UI). Feedback appreciated on whether to commit this, or recommendation for alternate approach.

          Alan Harder added a comment -

          Created an attachment (id=566)
          don't poll while checkout/update is running

          Alan Harder added a comment - Created an attachment (id=566) don't poll while checkout/update is running

          Alan Harder added a comment -

          guess I could simplify by using SCMTrigger.getLock() for locking from
          AbstractProject.checkout, rather than using the ResourceController system.

          Alan Harder added a comment - guess I could simplify by using SCMTrigger.getLock() for locking from AbstractProject.checkout, rather than using the ResourceController system.

          Alan Harder added a comment -

          yes, that was much simpler.. going to commit using SCMTrigger.getLock() directly
          in checkout() when a SCMTrigger is present.

          Alan Harder added a comment - yes, that was much simpler.. going to commit using SCMTrigger.getLock() directly in checkout() when a SCMTrigger is present.

          Code changed in hudson
          User: : mindless
          Path:
          trunk/hudson/main/core/src/main/java/hudson/model/AbstractProject.java
          trunk/hudson/main/test/src/test/java/hudson/triggers/SCMTriggerTest.java
          trunk/www/changelog.html
          http://fisheye4.cenqua.com/changelog/hudson/?cs=15377
          Log:
          [FIXED JENKINS-2671] lock the SCMTrigger.getLock() in checkout() so polling won't occur
          while the checkout/update is in progress.

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/hudson/main/core/src/main/java/hudson/model/AbstractProject.java trunk/hudson/main/test/src/test/java/hudson/triggers/SCMTriggerTest.java trunk/www/changelog.html http://fisheye4.cenqua.com/changelog/hudson/?cs=15377 Log: [FIXED JENKINS-2671] lock the SCMTrigger.getLock() in checkout() so polling won't occur while the checkout/update is in progress.

            mindless Alan Harder
            bharathnair bharathnair
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: