Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-4270

SVN polling, clean builds, and long checkout equal endless loop

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • subversion-plugin
    • None
    • Platform: All, OS: All

      I was using svn polling once every minute (* * * * *) and the clean build option. My
      checkout time exceeds one minute.

      So what happens is...
      1) A build is triggered, this deletes the workspace (clean).
      2) The svn checkout begins (more than 60s elapse).
      3) Hudson svn polling tries to query the workspace to see if there are any updates, but the
      workspace is not done checking out from step 2. This causes the following message:

      Started on Aug 19, 2009 12:00:54 PM
      Workspace doesn't contain http://xxxxxxxxxxxxxxxxxxxxxxxxxx. Need a new build
      Done. Took 0.2 sec
      Changes found

      4) A new build is scheduled even though there are no new changes. Goto to step 1).

      This creates an endlessly looping build.

      A quick fix would be to suspend polling a project if a checkout/update is in progress.

      Alternately, you could query the repository directly (i.e. svn log --limit 1
      http://svnrepo/code/some/project) and compare the result to the previous change which
      triggered a build.

      You can workaround this issue by changing your poll schedule to something less frequent
      which will allow your build time to finish the checkout.

          [JENKINS-4270] SVN polling, clean builds, and long checkout equal endless loop

          gregan created issue -

          williamleara added a comment -

          I think I'm seeing the same thing. However, my jobs are configured to "Use
          update". I'm getting the same polling log message. I never had this problem
          until I upgraded from 1.318 to 1.320. (skipped over 1.319)

          williamleara added a comment - I think I'm seeing the same thing. However, my jobs are configured to "Use update". I'm getting the same polling log message. I never had this problem until I upgraded from 1.318 to 1.320. (skipped over 1.319)

          williamleara added a comment -

          gregan, do you know exactly with which build of Hudson this issue began? I
          don't think it was there at 1.317.

          williamleara added a comment - gregan, do you know exactly with which build of Hudson this issue began? I don't think it was there at 1.317.

          dlindner added a comment -

          I can confirm this behaviour for a master/slave setup.
          Whenever a change happens and the checkout lasts longer than the polling
          interval (every minute in my case), a second build gets triggered. The build
          will report "no changes" afterwards.

          The problem started after version 1.318 and still persists.

          dlindner added a comment - I can confirm this behaviour for a master/slave setup. Whenever a change happens and the checkout lasts longer than the polling interval (every minute in my case), a second build gets triggered. The build will report "no changes" afterwards. The problem started after version 1.318 and still persists.

          gregan added a comment -

          Prior to 318, I was only building smaller libraries with short checkout times.

          I'll try to find time this week to downgrade to 316 or 317 and try to reproduce
          the problem.

          gregan added a comment - Prior to 318, I was only building smaller libraries with short checkout times. I'll try to find time this week to downgrade to 316 or 317 and try to reproduce the problem.

          etomhel added a comment -

          I have the same problem and I'm also using update instead och checking out a
          fresh workspace. The update process takes longer time than the polling interval,
          and when the polling occurs during an update it directly schedules a new build.

          I tried going back to 1.318, but it complained about missing the class
          hudson.tasks.BuildStepMonitor, so I'm stuck with 1.322 and this problem now.

          etomhel added a comment - I have the same problem and I'm also using update instead och checking out a fresh workspace. The update process takes longer time than the polling interval, and when the polling occurs during an update it directly schedules a new build. I tried going back to 1.318, but it complained about missing the class hudson.tasks.BuildStepMonitor, so I'm stuck with 1.322 and this problem now.

          etomhel added a comment -

          More information on this problem in this thread:

          http://www.nabble.com/1.322-subversion-polling-appears-differently-broken-td25240052.html

          etomhel added a comment - More information on this problem in this thread: http://www.nabble.com/1.322-subversion-polling-appears-differently-broken-td25240052.html

          mdonohue added a comment -
              • Issue 4310 has been marked as a duplicate of this issue. ***

          mdonohue added a comment - Issue 4310 has been marked as a duplicate of this issue. ***
          mdonohue made changes -
          Link New: This issue is duplicated by JENKINS-4310 [ JENKINS-4310 ]

          tugboat_1 added a comment -

          I ran into this bug, as I moved the build server from a single core machine to a
          dual core machine.

          tugboat_1 added a comment - I ran into this bug, as I moved the build server from a single core machine to a dual core machine.

            abayer Andrew Bayer
            gregan gregan
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: