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

Subversion fails to update externals once after external is changed.

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • subversion-plugin
    • Jenkins ver. 1.565.1 running on Windows Server 2012.
      Slaves running on Mac, Linux, and Windows, all affected.
      Subversion Plugin 2.3

      SVN Check out fails at external check-out.

      This only occurs if the external has changed. In this case, the external revision was updated to a more recent version. (For us, this happens maybe once a week so).

      We run quite a number of jobs that access this same repository. Whenever the SVN External is changed, they all fail. They all fail only once and are fine the next time they run.

      The jobs themselves run on multiple machines from a pool. An individual machine does not impact the above. So, if the job-A runs on machine-X after the external change, job-A will fail. If job-B then runs on machine-X, it will fail. Then if job-A runs on machine-Y, it’s fine. Jobs need to get through this fail, machines do not.

      Note we have other jobs that use Subversion on the command line; they check out the same code but do not hit this problem.

      Our jobs are configured using a shared workspace.

      The externals all have the same access credentials. We have configured ‘Additional Credentials’ as well as the Subversion Credentials, but all are the same. Also, as this only happens after an external change, all work correctly.

      13:03:47 Fetching 'https://repo/product/trunk/tools/scripts/pyadb' at -1 into '/local/ws/BUILD_PRODUCT_TRUNK/tools/scripts/jenkins/canaries/pyadb'
      13:03:47 At revision 193923
      13:03:47 At revision 193923
      13:03:48 no change for https://repo/product/trunk/components/csf-foundation/include since the previous build
      13:03:48 no change for https://repo/product/trunk/components/common-foundation/CommonFoundation since the previous build
      13:03:48 hudson.util.IOException2: revision check failed on https://repo/product/thirdparty-allversions/internal/sipcc/imports/IMPORT_synbase_main
      13:03:48 at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:186)
      13:03:48 at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:128)
      13:03:48 at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:739)
      13:03:48 at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:900)
      13:03:48 at hudson.model.AbstractProject.checkout(AbstractProject.java:1252)
      13:03:48 at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:615)
      13:03:48 at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
      13:03:48 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:524)
      13:03:48 at hudson.model.Run.execute(Run.java:1706)
      13:03:48 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      13:03:48 at hudson.model.ResourceController.execute(ResourceController.java:88)
      13:03:48 at hudson.model.Executor.run(Executor.java:232)
      13:03:48 Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /product/thirdparty-allversions/internal/sipcc/imports/IMPORT_synbase_main failed
      13:03:48 at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384)
      13:03:48 at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
      13:03:48 at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
      13:03:48 at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
      13:03:48 at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
      13:03:48 at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
      13:03:48 at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020)
      13:03:48 at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180)
      13:03:48 at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
      13:03:48 at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)
      13:03:48 at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
      13:03:48 at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
      13:03:48 at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
      13:03:48 at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
      13:03:48 at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
      13:03:48 at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
      13:03:48 at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967)
      13:03:48 at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
      13:03:48 at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:174)
      13:03:48 ... 11 more
      13:03:48 Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
      13:03:48 at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
      13:03:48 at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
      13:03:48 at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185)
      13:03:48 at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:694)
      13:03:48 at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
      13:03:48 ... 29 more

          [JENKINS-25070] Subversion fails to update externals once after external is changed.

          James Noonan created issue -

          Daniel Beck added a comment -

          Externals need 'Additional Credentials' defined, see JENKINS-21785. Did you specify those?

          (Please don't post a comment there, it's too noisy already)

          Daniel Beck added a comment - Externals need 'Additional Credentials' defined, see JENKINS-21785 . Did you specify those? (Please don't post a comment there, it's too noisy already)

          James Noonan added a comment -

          Yes.

          The externals are all on the same repo. The same credentials are specified in 'Additional Credentials' as for the main subversion check-out.

          Also, 99% of the time, there is no problem. It seems to be only when the external revision changes. And we are on revision 2.3.

          James Noonan added a comment - Yes. The externals are all on the same repo. The same credentials are specified in 'Additional Credentials' as for the main subversion check-out. Also, 99% of the time, there is no problem. It seems to be only when the external revision changes. And we are on revision 2.3.

          Oleg Nenashev added a comment -

          @James.
          Do you explicitly specify @HEAD in Subversion repo path?
          If no, see JENKINS-1241

          Oleg Nenashev added a comment - @James. Do you explicitly specify @HEAD in Subversion repo path? If no, see JENKINS-1241

          James Noonan added a comment - - edited

          (thanks Oleg)

          We specify:
          https://repo-loc.company.com/product-all/product/trunk@$SVN_REVISION

          $SVN_REVISION is passed as a parameter to the build. We have a 'home-spun' matrix style build, so are forcing jobs to a specific revision.

          For credentials:

          • There are three 'mirrored' repos. All our externals are on our own repos. We therefore specifiy as an external each location with the appropriate credentials.

          As said, this works great, most of the time. It fails whenever an external changes. Then, each job fails once and then is fine. The jobs run on a pool of machines, so it's really each job, not machine.

          James Noonan added a comment - - edited (thanks Oleg) We specify: https://repo-loc.company.com/product-all/product/trunk@$SVN_REVISION $SVN_REVISION is passed as a parameter to the build. We have a 'home-spun' matrix style build, so are forcing jobs to a specific revision. For credentials: There are three 'mirrored' repos. All our externals are on our own repos. We therefore specifiy as an external each location with the appropriate credentials. As said, this works great, most of the time. It fails whenever an external changes. Then, each job fails once and then is fine. The jobs run on a pool of machines, so it's really each job, not machine.

          Oleg Nenashev added a comment - - edited

          I would re-open JENKINS-21785 for the issue.
          The behavior is very similar, so there could be a partial fix only in 2.3

          I tried to reproduce the case on our dev. servers, but wasn't very successful on this front

          Oleg Nenashev added a comment - - edited I would re-open JENKINS-21785 for the issue. The behavior is very similar, so there could be a partial fix only in 2.3 I tried to reproduce the case on our dev. servers, but wasn't very successful on this front
          Oleg Nenashev made changes -
          Link New: This issue is related to JENKINS-21785 [ JENKINS-21785 ]
          Oleg Nenashev made changes -
          Link New: This issue is related to JENKINS-22351 [ JENKINS-22351 ]

          We have been experiencing a similar exception intermittently during updates executed when Jenkins does a build of our software.

          Based on James Noonan's findings, we tried changing a file in a directory that is referenced as an external. The first build's update/checkout failed with the subversion exception, and then the second build updated without any error. We have reproduced this pattern more than three times now.

          Our plugin is version 2.4.3. Is there any other information we could collect to assist with pinning this down?

          timothy luksha added a comment - We have been experiencing a similar exception intermittently during updates executed when Jenkins does a build of our software. Based on James Noonan's findings, we tried changing a file in a directory that is referenced as an external. The first build's update/checkout failed with the subversion exception, and then the second build updated without any error. We have reproduced this pattern more than three times now. Our plugin is version 2.4.3. Is there any other information we could collect to assist with pinning this down?

          James Noonan added a comment -

          Hi,

          We've updated to Subversion 2.4.4. We also updated to Jenkins ver. 1.565.3.
          However, the problem still occurs, and is quite reproducible.

          @Oleg; I'm reluctant to re-open that defect. While it's likely similar, there are clear instructions at the top of that defect, and we have followed them all.

          James Noonan added a comment - Hi, We've updated to Subversion 2.4.4. We also updated to Jenkins ver. 1.565.3. However, the problem still occurs, and is quite reproducible. @Oleg; I'm reluctant to re-open that defect. While it's likely similar, there are clear instructions at the top of that defect, and we have followed them all.

            Unassigned Unassigned
            jnoonan33 James Noonan
            Votes:
            16 Vote for this issue
            Watchers:
            18 Start watching this issue

              Created:
              Updated:
              Resolved: