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

"Double Build" Polling Issue with Subversion Plugin

    Details

    • Similar Issues:

      Description

      We are using the SVN polling option for Jenkins. It is set to poll the SVN repository once a minute.

      The polling log states:

      Started on Feb 7, 2012 11:07:02 AM
      Received SCM poll call on for n-oa on Feb 7, 2012 11:07:02 AM
      https://XXXXXX is at revision 19,322
      (changed from 19,321)
      Done. Took 0.25 sec
      Changes found

      Under "Changes" on the page for the given build, there is the following:

      Revision: 19321
      No changes.

      But then the job never performs the SVN update on the workspace, building from the old codebase. The next poll detects the change, updates the workspace, and builds again. This produces 2 builds for some commits.

      We have not been able to determine what triggers the "double build", because, though it is happening often, it doesn't happen every time.

        Attachments

          Activity

          Hide
          mjobin Mathieu Jobin added a comment -

          similar issue with Git pulling. using Jenkins ver. 1.474

          Show
          mjobin Mathieu Jobin added a comment - similar issue with Git pulling. using Jenkins ver. 1.474
          Hide
          kutzi kutzi added a comment -

          Are the clocks of your subversion server and your Jenkins server(s) in sync?

          Show
          kutzi kutzi added a comment - Are the clocks of your subversion server and your Jenkins server(s) in sync?
          Hide
          mjobin Mathieu Jobin added a comment -

          in our case, we do not have a subversion server. we are using git and our remote is github.com. I am trusting they are synchronized, although I cannot verify.

          our jenkins server shows the following.

          looks like we may have a little delay. but I'm not an ntp specialist

          ntpq> peers
          remote refid st t when poll reach delay offset jitter
          ==============================================================================
          +173.44.32.10 128.138.140.44 2 u 757 1024 177 27.666 -25.743 21.265
          *lswb-man-01.ser 209.51.161.238 2 u 587 1024 377 2.216 -36.146 21.229
          ntpq>

          you think this could be the cause? I can try to reduce that offset.

          Show
          mjobin Mathieu Jobin added a comment - in our case, we do not have a subversion server. we are using git and our remote is github.com. I am trusting they are synchronized, although I cannot verify. our jenkins server shows the following. looks like we may have a little delay. but I'm not an ntp specialist ntpq> peers remote refid st t when poll reach delay offset jitter ============================================================================== +173.44.32.10 128.138.140.44 2 u 757 1024 177 27.666 -25.743 21.265 *lswb-man-01.ser 209.51.161.238 2 u 587 1024 377 2.216 -36.146 21.229 ntpq> you think this could be the cause? I can try to reduce that offset.
          Hide
          mjobin Mathieu Jobin added a comment -

          oh, its in ms, -36.146ms does not sounds like a bad time difference

          I think we're good.

          Show
          mjobin Mathieu Jobin added a comment - oh, its in ms, -36.146ms does not sounds like a bad time difference I think we're good.
          Hide
          kutzi kutzi added a comment -

          Mathieu, this issue is specifically about the subversion plugin. If you have a similar problem with the git plugin, that is still a different issue.

          Show
          kutzi kutzi added a comment - Mathieu, this issue is specifically about the subversion plugin. If you have a similar problem with the git plugin, that is still a different issue.
          Hide
          shawnmjones Shawn M. Jones added a comment - - edited

          I apologize for not updating this ticket.

          Our problem was the time sync. We now ensure that the SVN and Jenkins servers are using the same NTP server. At the time I posted this, we did not control our SVN server, and could not make that happen, but now we're ok.

          I understand that Jenkins wouldn't want to build code from the future because it can have ramifications on your CM processes, but what actually causes this problem with Jenkins? The "double builds" are a really strange symptom of time differences.

          Show
          shawnmjones Shawn M. Jones added a comment - - edited I apologize for not updating this ticket. Our problem was the time sync. We now ensure that the SVN and Jenkins servers are using the same NTP server. At the time I posted this, we did not control our SVN server, and could not make that happen, but now we're ok. I understand that Jenkins wouldn't want to build code from the future because it can have ramifications on your CM processes, but what actually causes this problem with Jenkins? The "double builds" are a really strange symptom of time differences.
          Hide
          kutzi kutzi added a comment -

          The problem is that the methods to determine changes are not quite consistent between polling and the actual builds. This is a known shortcoming of the Jenkins/subversion-plugin. It's not easy to fix without causing other issues. However, synchronising the time is an easy way to remedy it.

          Show
          kutzi kutzi added a comment - The problem is that the methods to determine changes are not quite consistent between polling and the actual builds. This is a known shortcoming of the Jenkins/subversion-plugin. It's not easy to fix without causing other issues. However, synchronising the time is an easy way to remedy it.

            People

            • Assignee:
              Unassigned
              Reporter:
              shawnmjones Shawn M. Jones
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: