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

"Double Build" Polling Issue with Subversion Plugin

XMLWordPrintable

      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.

          [JENKINS-12670] "Double Build" Polling Issue with Subversion Plugin

          Mathieu Jobin added a comment -

          similar issue with Git pulling. using Jenkins ver. 1.474

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

          kutzi added a comment -

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

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

          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.

          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.

          Mathieu Jobin added a comment -

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

          I think we're good.

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

          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.

          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.

          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.

          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.

          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.

          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.

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

              Created:
              Updated:
              Resolved: