[JIRA] [subversion-plugin] (JENKINS-31455) Build instability with "ISVNAuthentication provider did not provide credentials"

41 views
Skip to first unread message

me@thomaskeller.biz (JIRA)

unread,
Nov 9, 2015, 5:46:02 AM11/9/15
to jenkinsc...@googlegroups.com
Thomas Keller created an issue
 
Jenkins / Bug JENKINS-31455
Build instability with "ISVNAuthentication provider did not provide credentials"
Issue Type: Bug Bug
Assignee: Unassigned
Components: subversion-plugin
Created: 09/Nov/15 10:45 AM
Priority: Minor Minor
Reporter: Thomas Keller

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://svn-external.loyaltypartner.com/repos/PB_MOBILE/DOCUMENTATION/03_Backend/trunk/05_Textstrings/ShoppingAPP/android/dsa/mx/stringsDSA.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
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

me@thomaskeller.biz (JIRA)

unread,
Nov 9, 2015, 5:47:01 AM11/9/15
to jenkinsc...@googlegroups.com
Thomas Keller updated an issue
Change By: Thomas Keller
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:

{code}
hudson.util.IOException2: revision check failed on http:// svn-external.loyaltypartner.com host / repos path / PB_MOBILE to / DOCUMENTATION/03_Backend/trunk/05_Textstrings/ShoppingAPP/android/dsa/mx/stringsDSA external .xml
{code}


Jenkins 1.635
Subversion plugin 2.5.3

me@thomaskeller.biz (JIRA)

unread,
Nov 18, 2015, 8:25:01 AM11/18/15
to jenkinsc...@googlegroups.com
Thomas Keller updated an issue
Change By: Thomas Keller
Priority: Minor Major

recena@gmail.com (JIRA)

unread,
Nov 23, 2015, 3:54:01 AM11/23/15
to jenkinsc...@googlegroups.com
Manuel Jesús Recena Soto commented on Bug JENKINS-31455
 
Re: Build instability with "ISVNAuthentication provider did not provide credentials"

Thomas Keller, I recommend you to upgrade to 2.5.4. Could you provide the job configuration?

recena@gmail.com (JIRA)

unread,
Nov 23, 2015, 3:54:02 AM11/23/15
to jenkinsc...@googlegroups.com
Change By: Manuel Jesús Recena Soto
Assignee: Manuel Jesús Recena Soto

axel.mueller@avanux.de (JIRA)

unread,
Feb 10, 2016, 7:46:02 AM2/10/16
to jenkinsc...@googlegroups.com
Axel Müller commented on Bug JENKINS-31455
 
Re: Build instability with "ISVNAuthentication provider did not provide credentials"

We have exactly the same problem on a Jenkins slave. The checkout involves SNV externals as well.

axel.mueller@avanux.de (JIRA)

unread,
Feb 10, 2016, 7:46:03 AM2/10/16
to jenkinsc...@googlegroups.com
Axel Müller edited a comment on Bug JENKINS-31455
We have exactly the same problem on a Jenkins slave. The checkout involves SNV externals as well.  I can provide the job configuration if required.

preid@electromag.com.au (JIRA)

unread,
Feb 14, 2016, 11:11:03 PM2/14/16
to jenkinsc...@googlegroups.com
Phil R commented on Bug JENKINS-31455

Same or very similar problem with externals.
Jenkins 1.647. SVN Plugin 2.5.7
Setup Additional Credentials but still see the occasional failures.
Running on Windows 7 box with newly update java re.

patrick.bindy@schaerer.com (JIRA)

unread,
Feb 25, 2016, 2:41:03 AM2/25/16
to jenkinsc...@googlegroups.com

I do have the same issue as well with externals:

Jenkins 1.648 SVN Plugin 2.5.88

Setup Additional Credentials, but still has occasional failures.
Windows 7 installed

mkaiser@cit-ec.uni-bielefeld.de (JIRA)

unread,
Mar 4, 2016, 9:51:02 AM3/4/16
to jenkinsc...@googlegroups.com

Same problem here:

  • most of the time it works when the build is triggered manually
  • if build is triggered by svn-polling, every access every nested/external svn. The projects "main" repo can be accessed successfully.
  • Jenkins ver. 1.642.2
  • Subversion Plug-in: 2.5.7
  • Ubuntu 14.04

joe.noel@focusrite.com (JIRA)

unread,
Apr 7, 2016, 7:24:01 AM4/7/16
to jenkinsc...@googlegroups.com
Joe Noel commented on Bug JENKINS-31455

We have the same issue:

  • Jenkins 1.578 (update pending...)
  • Subversion Plug-in 2.5.7
  • Windows 7 x64 slave

wade.dawson@focusrite.com (JIRA)

unread,
Apr 7, 2016, 8:22:03 AM4/7/16
to jenkinsc...@googlegroups.com

Also having the issue...
SVNPlug 2.5.7
Jenkins 1.578
Windows 7 64 bit build slave

drkstr101@gmail.com (JIRA)

unread,
Apr 12, 2016, 8:52:03 PM4/12/16
to jenkinsc...@googlegroups.com

Happens rather consistently here (close to every-other build). I would happily accept any consistent work around.

Jenkins: 1.656
Subversion: 2.5.7
Ubuntu 14.04.4 LTS

Example Config:

<?xml version='1.0' encoding='UTF-8'?>
<project>
  <actions/>
  <description></description>
  <keepDependencies>false</keepDependencies>
  <properties>
    <hudson.plugins.mantis.MantisProjectProperty plugin="man...@0.26">
      <siteName>http://jenkins.my.local/mantisbt/</siteName>
      <projectId>-1</projectId>
      <category>Not Selected</category>
      <regexpPattern>
        <pattern>(?&lt;=issue #?)(\d+)(?=)</pattern>
        <flags>0</flags>
      </regexpPattern>
      <linkEnabled>false</linkEnabled>
    </hudson.plugins.mantis.MantisProjectProperty>
  </properties>
  <scm class="hudson.scm.SubversionSCM" plugin="subve...@2.5.7">
    <locations>
      <hudson.scm.SubversionSCM_-ModuleLocation>
        <remote>http://vlstb2.my.local:222/svn/widget/trunk</remote>
        <credentialsId>5b01e1f8-4d5b-487e-8b66-1143d4bca506</credentialsId>
        <local>.</local>
        <depthOption>infinity</depthOption>
        <ignoreExternalsOption>false</ignoreExternalsOption>
      </hudson.scm.SubversionSCM_-ModuleLocation>
    </locations>
    <additionalCredentials>
      <hudson.scm.SubversionSCM_-AdditionalCredentials>
        <realm>http://vlstb2.my.local:222/svn/externs</realm>
        <credentialsId>5b01e1f8-4d5b-487e-8b66-1143d4bca506</credentialsId>
      </hudson.scm.SubversionSCM_-AdditionalCredentials>
      <hudson.scm.SubversionSCM_-AdditionalCredentials>
        <realm>http://vlstb2.my.local:222/svn/commons/trunk</realm>
        <credentialsId>5b01e1f8-4d5b-487e-8b66-1143d4bca506</credentialsId>
      </hudson.scm.SubversionSCM_-AdditionalCredentials>
      <!-- trimmed 3 more.. -->
    </additionalCredentials>
    <excludedRegions></excludedRegions>
    <includedRegions></includedRegions>
    <excludedUsers></excludedUsers>
    <excludedRevprop></excludedRevprop>
    <excludedCommitMessages></excludedCommitMessages>
    <workspaceUpdater class="hudson.scm.subversion.UpdateUpdater"/>
    <ignoreDirPropChanges>false</ignoreDirPropChanges>
    <filterChangelog>false</filterChangelog>
  </scm>
  <canRoam>true</canRoam>
  <disabled>false</disabled>
  <blockBuildWhenDownstreamBuilding>false</blockBuildWhenDownstreamBuilding>
  <blockBuildWhenUpstreamBuilding>true</blockBuildWhenUpstreamBuilding>
  <triggers>
    <jenkins.triggers.ReverseBuildTrigger>
      <spec></spec>
      <upstreamProjects>commons,externs/font-awesome/trunk,externs/jquery-mobile/trunk,externs/createjs/trunk,</upstreamProjects>
      <threshold>
        <name>SUCCESS</name>
        <ordinal>0</ordinal>
        <color>BLUE</color>
        <completeBuild>true</completeBuild>
      </threshold>
    </jenkins.triggers.ReverseBuildTrigger>
    <hudson.triggers.SCMTrigger>
      <spec>@midnight</spec>
      <ignorePostCommitHooks>false</ignorePostCommitHooks>
    </hudson.triggers.SCMTrigger>
  </triggers>
  <concurrentBuild>false</concurrentBuild>
  <builders>
    <hudson.tasks.Ant plugin="ant@1.2">
      <targets>clean build test</targets>
      <antName>(Default)</antName>
      <properties>sass.cmd=/usr/local/bin/sass</properties>
    </hudson.tasks.Ant>
  </builders>
  <publishers>
    <hudson.tasks.junit.JUnitResultArchiver plugin="ju...@1.11">
      <testResults>build/report/xunit/*.xml</testResults>
      <keepLongStdio>false</keepLongStdio>
      <healthScaleFactor>1.0</healthScaleFactor>
      <allowEmptyResults>false</allowEmptyResults>
    </hudson.tasks.junit.JUnitResultArchiver>
  </publishers>
  <buildWrappers>
    <hudson.plugins.ansicolor.AnsiColorBuildWrapper plugin="ansi...@0.4.2">
      <colorMapName>xterm</colorMapName>
    </hudson.plugins.ansicolor.AnsiColorBuildWrapper>
  </buildWrappers>
</project>

Cheers and thanks for your time!

stephan.grimm@sonova.com (JIRA)

unread,
Jun 17, 2016, 6:31:02 AM6/17/16
to jenkinsc...@googlegroups.com

Hi

On our buildserver it happens reproducible every time after committing something in the external folder and trigger a build. A following build is then always successfully.

  • Jenkins 2.9
  • Subversion 2.5.7
  • Windows 7

Does anybody knows a working work around?

  • downgrade to an older Jenkins version
  • downgrade to an older Subversion plugin version
  • ...

Thanks,
Stephan
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

w.monsuwe@stater.nl (JIRA)

unread,
Jun 29, 2016, 6:05:02 AM6/29/16
to jenkinsc...@googlegroups.com

We have the same problem. Downgrading the subversion plugin all the way to 2.5 fixes the issue.
However, this is not a solution since we need version 2.5.5+ because we're using file:// access to some repositories that were touched by an 1.9 client.

w.monsuwe@stater.nl (JIRA)

unread,
Jun 29, 2016, 8:11:02 AM6/29/16
to jenkinsc...@googlegroups.com
Willem Monsuwe edited a comment on Bug JENKINS-31455
We have the same problem.  Downgrading the subversion plugin all the way to 2.5 fixes the issue.
However, this is not a solution since we need version 2.5.5+ because we're using file:// access to some repositories that were touched by an 1.9 client.


EDIT:  The issue seems to be fixed by providing the correct and complete realm in the 'realm' field.
With 2.5 the value '<http://svnserver:80>' worked.
But with 2.5.5+ it needs to be '<http://svnserver:80> Svn Authrntication realm'

w.monsuwe@stater.nl (JIRA)

unread,
Jun 29, 2016, 8:12:02 AM6/29/16
to jenkinsc...@googlegroups.com
Willem Monsuwe edited a comment on Bug JENKINS-31455
We have the same problem.  Downgrading the subversion plugin all the way to 2.5 fixes the issue.
However, this is not a solution since we need version 2.5.5+ because we're using file:// access to some repositories that were touched by an 1.9 client.

EDIT:  The issue seems to be fixed by providing the correct and complete realm in the 'realm' field.
With 2.5 the value ' {color:blue} <http://svnserver:80> {color} ' worked.
But with 2.5.5+ it needs to be ' {color:blue} <http://svnserver:80> {color}{color:red} Svn Authrntication Authentication realm {color} '

joachim.herb@gmx.de (JIRA)

unread,
Jun 29, 2016, 1:30:02 PM6/29/16
to jenkinsc...@googlegroups.com

Unfortunately, I cannot confirm that downgrading to version 2.5 of the subversion plugin fixes the problem: I still see it (nearly) every second build in pipeline jobs:
The checkout of the external SVN project fails with the authentication error. The external project is hosted on the same SVN server as the base project and the same username/password combination is used for the external project as for the base project.

No realm is specified in the pipeline job configuration, but the checkout is done within a groovy pipeline script using the following code:

    checkout scm: [
        $class: 'SubversionSCM',
        locations: [[
            remote: "https://some.server/xxx/",
            local: 'yyy',
            credentialsId: credentialsId,
            depthOption: 'files',
            depthOption: 'infinity',
            ignoreExternalsOption: false
        ]],
        workspaceUpdater: [
            $class: 'UpdateUpdater'
        ]
    ]

The variable credentialsId contains contains the ID from https://jenkins.server/credentials/store/system/domain/_/credential/
(Credentials)

I also tested if a loop around the checkout commands with a number of retries and a delay between them helps, but also not. Only "replay"ing the same job fixes the problem (temporarily).

So a workaround would be to catch the checkout exception in the Jenkinsfile and restart/trigger the same job with the same parameters again. Is there a simple way for this (especially reuse the same parameters)?

joachim.herb@gmx.de (JIRA)

unread,
Jun 29, 2016, 1:31:04 PM6/29/16
to jenkinsc...@googlegroups.com
Joachim Herb edited a comment on Bug JENKINS-31455
Unfortunately, I cannot confirm that downgrading to version 2.5 of the subversion plugin fixes the problem: I still see it (nearly) every second build in pipeline jobs:
The checkout of the external SVN project fails with the authentication error. The external project is hosted on the same SVN server as the base project and the same username/password combination is used for the external project as for the base project.

No realm is specified in the pipeline job configuration, but the checkout is done within a groovy pipeline script using the following code:


{code:java}

    checkout scm: [
        $class: 'SubversionSCM',
        locations: [[
            remote: "https://some.server/xxx/",
            local: 'yyy',
            credentialsId: credentialsId,
            depthOption: '
files',
            depthOption: ' infinity',

            ignoreExternalsOption: false
        ]],
        workspaceUpdater: [
            $class: 'UpdateUpdater'
        ]
    ]
{code}


The variable credentialsId contains contains the ID from https://jenkins.server/credentials/store/system/domain/_/credential/
(Credentials)

I also tested if a loop around the checkout commands with a number of retries and a delay between them helps, but also not. Only "replay"ing the same job fixes the problem (temporarily).

So a workaround would be to catch the checkout exception in the Jenkinsfile and restart/trigger the same job with the same parameters again. Is there a simple way for this (especially reuse the same parameters)?

joachim.herb@gmx.de (JIRA)

unread,
Jul 15, 2016, 7:44:03 AM7/15/16
to jenkinsc...@googlegroups.com

I created a work around by adding a try / catch block around the checkout scm command and in the catch block issue an svn update by sh (on Linux)/bat (on Windows).

By the way, this seems to be a duplicate of: https://issues.jenkins-ci.org/browse/JENKINS-25070

nils.ballmann.ext@siemens.com (JIRA)

unread,
Jul 18, 2016, 10:16:04 AM7/18/16
to jenkinsc...@googlegroups.com

With

  • Jenkins: 2.7.1
  • subversion-plugin: 2.6.0
  • Master: Windows Server
  • Slave: Windows 7

the problem is still there, but the workaround mentioned in https://issues.jenkins-ci.org/browse/JENKINS-21785 (additional credentials with auth realm) seems to be working.

From our findings, there seem to be two problems:
1. The subversion-plugin seems to be forgetting to send the authentication credentials at some svn:external call.
2. After the failed call due to unauthorized access (because of missing credentials) there seems to be a second call to the same svn:external with credentials, which then will be answered correctly, but the exception is still thrown with the authentication error.

These assumptions are based on the following SVN server access logs:

<IP> - <username> [12/Jul/2016:17:27:14 +0200] "REPORT /repos/<project a>/!svn/vcc/default HTTP/1.1" 200 31394267 "-" "SVN/1.8.1 SVNKit/1.8.11 (http://svnkit.com/) r10483_v20150925_0010"
<IP> - - [12/Jul/2016:17:27:17 +0200] "OPTIONS /repos/<project a>/libs/<folder a>/tags/<tag a>/out HTTP/1.1" 401 381 "-" "SVN/1.8.1 SVNKit/1.8.11 (http://svnkit.com/) r10483_v20150925_0010"
<IP> - <username> [12/Jul/2016:17:27:17 +0200] "OPTIONS /repos/<project a>/libs/<folder a>/tags/<tag a>/out HTTP/1.1" 200 196 "-" "SVN/1.8.1 SVNKit/1.8.11 (http://svnkit.com/) r10483_v20150925_0010"
<IP> - <username> [12/Jul/2016:17:27:18 +0200] "PROPFIND /repos/<project a>/libs/<folder a>/tags/<tag a>/out HTTP/1.1" 207 766 "-" "SVN/1.8.1 SVNKit/1.8.11 (http://svnkit.com/) r10483_v20150925_0010"

I hope this helps finding the underlying issue.

We also found out, the load on the server seems to be relevant. We measured the rate of failure by having four jobs checking out a fresh copy of the same repository (with externals) every ten minutes. Normally this checkout is about 3.5 minutes. The checkouts tend to get longer and longer up to 5 minutes. Then there is a job failure. The next 3-4 checkouts are back to 3.5minutes. Then there is a job failure. And then its back to normal for an unknown time longer than 2-3hrs. On weekends (nobody working) there are no failures at all.

And both of the job failures are at about the same time in all four jobs. So they fail in the same five minutes range, one after the other.

Stack trace:

14:55:55 hudson.util.IOException2: revision check failed on https://<domain>/repos/<project b>/<folder b>/trunk/scripts
14:55:55 	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:208)
14:55:55 	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:138)
14:55:55 	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
14:55:55 	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
14:55:55 	at hudson.scm.SCM.checkout(SCM.java:485)
14:55:55 	at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
14:55:55 	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
14:55:55 	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
14:55:55 	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
14:55:55 	at hudson.model.Run.execute(Run.java:1741)
14:55:55 	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
14:55:55 	at hudson.model.ResourceController.execute(ResourceController.java:98)
14:55:55 	at hudson.model.Executor.run(Executor.java:410)
14:55:55 Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
14:55:55 svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
14:55:55 	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60)
14:55:55 	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
14:55:55 	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:793)
14:55:55 	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:398)
14:55:55 	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:386)
14:55:55 	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:863)
14:55:55 	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:699)
14:55:55 	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:118)
14:55:55 	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1049)
14:55:55 	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:189)
14:55:55 	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
14:55:55 	at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:184)
14:55:55 	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
14:55:55 	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
14:55:55 	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
14:55:55 	at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
14:55:55 	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
14:55:55 	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
14:55:55 	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968)
14:55:55 	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873)
14:55:55 	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:194)
14:55:55 	... 12 more
14:55:55 Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
14:55:55 	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:723)
14:55:55 	... 30 more
14:55:55 Started calculate disk usage of build

Which fits to:
https://github.com/jenkinsci/subversion-plugin/blob/2.6.0/src/main/java/hudson/scm/SubversionSCM.java#L860
and
https://github.com/jenkinsci/subversion-plugin/blob/2.6.0/src/main/java/hudson/scm/SubversionChangeLogBuilder.java#L208

jenkins@onixconsulting.co.uk (JIRA)

unread,
Sep 2, 2016, 9:31:05 AM9/2/16
to jenkinsc...@googlegroups.com

Hi,

We are also experiencing a similar or the same issue. Our build is affected every other build ie we get a "Success", followed by a "Failure". Nothing I have attempted changes this behaviour, I have tried adding/removing additional credentials for the SVN external, full checkouts instead of svn updates, clearing out the .subversion directory all to no avail.

No changes for https://subversion.local/svn/web/frontpage since the previous build
hudson.util.IOException2: revision check failed on https://subversion.local/svn/web/common_src/trunk/php
  at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:208)
  at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:138)
  at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
  at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
  at hudson.scm.SCM.checkout(SCM.java:495)
  at hudson.model.AbstractProject.checkout(AbstractProject.java:1278)
  at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
  at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
  at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
  at hudson.model.Run.execute(Run.java:1720)
  at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
  at hudson.model.ResourceController.execute(ResourceController.java:98)
  at hudson.model.Executor.run(Executor.java:404)
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:793)
  at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:398)
  at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:386)
  at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:863)
  at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:699)
  at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:118)
  at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1049)
  at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:189)
  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:1235)
  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:194)
  ... 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:723)
  ... 30 more
Finished: FAILURE

jenkins@onixconsulting.co.uk (JIRA)

unread,
Sep 2, 2016, 9:36:02 AM9/2/16
to jenkinsc...@googlegroups.com
Tom Smith edited a comment on Bug JENKINS-31455
Hi,

We are also experiencing a similar or the same issue. Our build is affected every other build ie we get a "Success", followed by a "Failure". Nothing I have attempted changes this behaviour, I have tried adding/removing additional credentials for the SVN external, full checkouts instead of svn updates, clearing out the .subversion directory all to no avail.
Jenkins: 2.20
Subversion Plugin: 2.6
Credentials Plugin: 2.1.4

 {code:java}
{code}

roytinker@gmail.com (JIRA)

unread,
Oct 3, 2016, 5:21:02 PM10/3/16
to jenkinsc...@googlegroups.com

I'm seeing this problem when attempting to configure a pipeline global library that checks out from SVN.

I tried the above workarounds with no success. What finally worked for me was to completely dodge the global pipeline configuration - and manually check out and load the library in each pipeline instead. Here's what that looks like: https://gist.github.com/RoyTinker/69d0f1b962cb91336db4d2180934af3e

jglick@cloudbees.com (JIRA)

unread,
Oct 4, 2016, 12:11:03 PM10/4/16
to jenkinsc...@googlegroups.com

stephenconnolly suggested this might be a symptom of incorrect remoting of credentials, which already caused us a headache in SECURITY-144.

jglick@cloudbees.com (JIRA)

unread,
Oct 4, 2016, 12:14:06 PM10/4/16
to jenkinsc...@googlegroups.com

Roy Tinker your problem may or may not be related. TBD whether it can be reproduced from scratch. Probably deserves its own integration test here.

zionyx@gmail.com (JIRA)

unread,
Dec 6, 2016, 3:55:02 AM12/6/16
to jenkinsc...@googlegroups.com
KY Lee updated an issue
 
Change By: KY Lee
Environment: Windows Server 2012 R2; Jenkins 2.19.3 with Subversion plugin 2.7.1

gustavo@gnustavo.com (JIRA)

unread,
Dec 6, 2016, 4:36:28 PM12/6/16
to jenkinsc...@googlegroups.com
Gustavo Chaves commented on Bug JENKINS-31455
 
Re: Build instability with "ISVNAuthentication provider did not provide credentials"

Isn't this related to JENKINS-29340? The simptoms seem to be the same and that issue was considered fixed on version 2.5.7 of the Subversion Plugin.

sam.hepenstal@gmail.com (JIRA)

unread,
Dec 19, 2016, 3:46:02 PM12/19/16
to jenkinsc...@googlegroups.com

Jenkins 2.19.4
Subversion 2.7.1

Having the same issue - only with projects that have svn externals. All in the same repository. Have tried adding additional credential.
Intermittent failure. Have not yet found a consistent pattern. Happens on manual trigger as well as poll. When externals have changed and when they haven't. Frequency, however, appears to be greater in those projects with a greater number of externals.
All jobs are pipeline. To add to the annoyance the commit history of the build is lost.

francisco.javier.arenales.castrodeza@ericsson.com (JIRA)

unread,
Jan 11, 2017, 6:35:02 AM1/11/17
to jenkinsc...@googlegroups.com

Jenkins 2.32.1
Subversion 2.7.1

Same issue. Is there any progress about it?

iliev.nedko@gmail.com (JIRA)

unread,
Jan 11, 2017, 9:28:04 AM1/11/17
to jenkinsc...@googlegroups.com

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@extronis.com (JIRA)

unread,
Jan 20, 2017, 3:48:03 AM1/20/17
to jenkinsc...@googlegroups.com

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@extronis.com (JIRA)

unread,
Jan 20, 2017, 3:49:05 AM1/20/17
to jenkinsc...@googlegroups.com
Victor Ott updated an issue
 
Change By: Victor Ott
Environment:
Windows Server 2012 R2; Jenkins 2.19.3 with Subversion plugin 2.7.1

Linux x86_64,

victor.ott@extronis.com (JIRA)

unread,
Jan 20, 2017, 3:49:14 AM1/20/17
to jenkinsc...@googlegroups.com
Victor Ott updated an issue
Change By: Victor Ott
Environment:
Windows Server 2012 R2; Jenkins 2.19.3 with Subversion plugin 2.7.1
Linux x86_64, Linux x86_64

victor.ott@extronis.com (JIRA)

unread,
Jan 20, 2017, 3:49:25 AM1/20/17
to jenkinsc...@googlegroups.com
Victor Ott updated an issue
Change By: Victor Ott
Environment:
Windows Server 2012 R2; Jenkins 2.19.3 with Subversion plugin 2.7.1
Linux x86_64, Linux x86_64 Jenkins ver. 2.19.4 with Subversion Plugin 2.7.1

jglick@cloudbees.com (JIRA)

unread,
Jan 30, 2017, 7:16:02 PM1/30/17
to jenkinsc...@googlegroups.com
Jesse Glick commented on Bug JENKINS-31455
 
Re: Build instability with "ISVNAuthentication provider did not provide credentials"

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

victor.ott@extronis.com (JIRA)

unread,
Feb 8, 2017, 11:43:02 AM2/8/17
to jenkinsc...@googlegroups.com

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

victor.ott@extronis.com (JIRA)

unread,
Feb 8, 2017, 11:44:02 AM2/8/17
to jenkinsc...@googlegroups.com
Victor Ott edited a comment on Bug JENKINS-31455

victor.ott@extronis.com (JIRA)

unread,
Feb 8, 2017, 12:12:03 PM2/8/17
to jenkinsc...@googlegroups.com

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

stephen.mccants@hcs.us.com (JIRA)

unread,
Mar 14, 2017, 10:41:08 AM3/14/17
to jenkinsc...@googlegroups.com

I'd prefer to leave this ticket open as Jesse Glick'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.
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

jglick@cloudbees.com (JIRA)

unread,
Mar 22, 2017, 5:39:02 PM3/22/17
to jenkinsc...@googlegroups.com

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

stephen.mccants@hcs.us.com (JIRA)

unread,
Mar 22, 2017, 6:27:02 PM3/22/17
to jenkinsc...@googlegroups.com

Jesse Glick, 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.

dimitkoto@java.net (JIRA)

unread,
Feb 13, 2018, 12:50:03 PM2/13/18
to jenkinsc...@googlegroups.com

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?

 

stephen.mccants@hcs.us.com (JIRA)

unread,
Feb 13, 2018, 3:00:04 PM2/13/18
to jenkinsc...@googlegroups.com

Dimitar Sakarov, as stated in JENKINS-32167, there is no owner or maintainer of this plugin.  There is a workaround provided in comments under JENKINS-32167.  Jesse Glick 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.

 

ifernandezcalvo@cloudbees.com (JIRA)

unread,
Apr 18, 2018, 5:43:19 AM4/18/18
to jenkinsc...@googlegroups.com
Ivan Fernandez Calvo closed an issue as Duplicate
 
Change By: Ivan Fernandez Calvo
Status: Open Closed
Resolution: Duplicate
Reply all
Reply to author
Forward
0 new messages