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

Build instability with "ISVNAuthentication provider did not provide credentials"

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • subversion-plugin
    • None
    • Windows Server 2012 R2; Jenkins 2.19.3 with Subversion plugin 2.7.1
      Linux x86_64, Jenkins ver. 2.19.4 with Subversion Plugin 2.7.1

      This is a follow-up on JENKINS-21785. We're bitten by the dreaded E200015: ISVNAuthentication provider did not provide credentials exception noted there. We have, however, set up additional credentials for all of our externals and most of the time this setup works, despite when its not. This happens only for every third to fifth build, so there seems to be a timing regression issue in there which makes our builds very unstable and flaky.

      Right now we have about five to six builds that use an SVN checkout with externals, of which four could be executed at the same time (the build slave they're running on, a Mac Mini, has four build processors).

      This is the complete stack trace:

      hudson.util.IOException2: revision check failed on http://host/path/to/external.xml
      	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:196)
      	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:137)
      	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:726)
      	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:861)
      	at hudson.scm.SCM.checkout(SCM.java:485)
      	at hudson.model.AbstractProject.checkout(AbstractProject.java:1275)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
      	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
      	at hudson.model.Run.execute(Run.java:1741)
      	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      	at hudson.model.ResourceController.execute(ResourceController.java:98)
      	at hudson.model.Executor.run(Executor.java:410)
      Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
      svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
      	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60)
      	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
      	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759)
      	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371)
      	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359)
      	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710)
      	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
      	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
      	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032)
      	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:175)
      	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
      	at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:184)
      	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
      	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
      	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
      	at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
      	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259)
      	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
      	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968)
      	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873)
      	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:184)
      	... 12 more
      Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
      	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:689)
      	... 30 more
      Retrying after 10 seconds
      

      Jenkins 1.635
      Subversion plugin 2.5.3

          [JENKINS-31455] Build instability with "ISVNAuthentication provider did not provide credentials"

          Jenkins ver. 1.642.2
          Subversion 2.7.1
          and
          Subversion 2.5.7
          Same issue. On some change in externals the Subversion plugin fails.
          I've one more observation, on change in external the build fails, but after that if you introduce new change in the external and then re-run the build, the build is successful.
          So we again hit the problem one fail followed by one success.

          Nedyalko Iliev added a comment - Jenkins ver. 1.642.2 Subversion 2.7.1 and Subversion 2.5.7 Same issue. On some change in externals the Subversion plugin fails. I've one more observation, on change in external the build fails, but after that if you introduce new change in the external and then re-run the build, the build is successful. So we again hit the problem one fail followed by one success.

          Victor Ott added a comment -

          We experience this same issue, but under Linux :

          • Linux x86_64, Kernel 3.0.101-65-default
          • JDK8 64bit
          • Jenkins ver. 2.19.4
          • Subversion Plugin 2.7.1

          No build pipelines, but multijobs, maybe also some freestyle jobs.

          Victor Ott added a comment - We experience this same issue, but under Linux : Linux x86_64, Kernel 3.0.101-65-default JDK8 64bit Jenkins ver. 2.19.4 Subversion Plugin 2.7.1 No build pipelines, but multijobs, maybe also some freestyle jobs.

          Jesse Glick added a comment -

          My understanding is that JENKINS-32167 provides a better discussion, namely that the project must be configured to exactly match a realm.

          Jesse Glick added a comment - My understanding is that JENKINS-32167 provides a better discussion, namely that the project must be configured to exactly match a realm.

          Victor Ott added a comment - - edited

          @jglick Thanks for the pointer to JENKINS-32167. I've added more details there in a comment.

          Victor Ott added a comment - - edited @ jglick Thanks for the pointer to JENKINS-32167 . I've added more details there in a comment .

          Victor Ott added a comment -

          Is it ok for everybody if we close this ticket as duplicate of JENKINS-32167 ?

          Victor Ott added a comment - Is it ok for everybody if we close this ticket as duplicate of JENKINS-32167 ?

          I'd prefer to leave this ticket open as jglick's code is only better error messages.  Really, the underlying code needs to be fixed so that it is intuitive and doesn't require comment strings to match.

          Stephen McCants added a comment - I'd prefer to leave this ticket open as jglick 's code is only better error messages.  Really, the underlying code needs to be fixed so that it is intuitive and doesn't require comment strings to match.

          Jesse Glick added a comment -

          Well I was not proposing to close JENKINS-32167 just on the basis of improving error messages.

          Jesse Glick added a comment - Well I was not proposing to close  JENKINS-32167  just on the basis of improving error messages.

          jglick, fair enough.  I wasn't sure what the long term plan was.  I'm okay with this being marked as a duplicate of JENKINS-32167.

          Stephen McCants added a comment - jglick , fair enough.  I wasn't sure what the long term plan was.  I'm okay with this being marked as a duplicate of JENKINS-32167 .

          Is this problem resolved in some other way, e.g. by using a newer Jenkins / SVN plugin / Credentials plugin?

          Is there a workaround other than just restarting the job (additional credentials didn't make it work)?

          And if the answers for both questions is No, then is there at least an ETA for the issue to be fixed anytime soon?

           

          Dimitar Sakarov added a comment - Is this problem resolved in some other way, e.g. by using a newer Jenkins / SVN plugin / Credentials plugin? Is there a workaround other than just restarting the job (additional credentials didn't make it work)? And if the answers for both questions is No, then is there at least an ETA for the issue to be fixed anytime soon?  

          dimitkoto, as stated in JENKINS-32167, there is no owner or maintainer of this plugin.  There is a workaround provided in comments under JENKINS-32167jglick provided some better feedback code, but I don't think that has ever shipped.  I looked at it and wrote a test case demonstrating the problem, but solving it was too complicated for the time I could devote to it.

          I don't think anything has changed since then.   Wish someone would step up and fix it for us users, but I'm not expecting it until the SVN plugin is totally busted.

           

          Stephen McCants added a comment - dimitkoto , as stated in  JENKINS-32167 , there is no owner or maintainer of this plugin.  There is a workaround provided in comments under JENKINS-32167 .  jglick provided some better feedback code, but I don't think that has ever shipped.  I looked at it and wrote a test case demonstrating the problem, but solving it was too complicated for the time I could devote to it. I don't think anything has changed since then.   Wish someone would step up and fix it for us users, but I'm not expecting it until the SVN plugin is totally busted.  

            recena Manuel Recena Soto
            thomaskeller Thomas Keller
            Votes:
            58 Vote for this issue
            Watchers:
            56 Start watching this issue

              Created:
              Updated:
              Resolved: