-
Bug
-
Resolution: Duplicate
-
Major
-
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
- duplicates
-
-
- Fixed but Unreleased
-
- is duplicated by
-
-
- Resolved
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Fixed but Unreleased
-
-
-
- Closed
-
- links to
[JENKINS-31455] 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. I can provide the job configuration if required.
Axel Müller
added a comment - - edited 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. 
Phil R
added a comment - 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.
Phil R
added a comment - 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
added a comment - 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
Patrick Bindy
added a comment - 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 
Martin Kaiser
added a comment - 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
Martin Kaiser
added a comment - 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
added a comment - We have the same issue:
- Jenkins 1.578 (update pending...)
- Subversion Plug-in 2.5.7
- Windows 7 x64 slave
Joe Noel
added a comment - We have the same issue:
Jenkins 1.578 (update pending...)
Subversion Plug-in 2.5.7
Windows 7 x64 slave
wade dawson
added a comment - Also having the issue...
SVNPlug 2.5.7
Jenkins 1.578
Windows 7 64 bit build slave
wade dawson
added a comment - Also having the issue...
SVNPlug 2.5.7
Jenkins 1.578
Windows 7 64 bit build slave 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="mantis@0.26"> <siteName>http://jenkins.my.local/mantisbt/</siteName> <projectId>-1</projectId> <category>Not Selected</category> <regexpPattern> <pattern>(?<=issue #?)(\d+)(?=)</pattern> <flags>0</flags> </regexpPattern> <linkEnabled>false</linkEnabled> </hudson.plugins.mantis.MantisProjectProperty> </properties> <scm class="hudson.scm.SubversionSCM" plugin="subversion@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="junit@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="ansicolor@0.4.2"> <colorMapName>xterm</colorMapName> </hudson.plugins.ansicolor.AnsiColorBuildWrapper> </buildWrappers> </project>
Cheers and thanks for your time!
Stephan Grimm
added a comment - 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
Stephan Grimm
added a comment - 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 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 Authentication realm'
Willem Monsuwe
added a comment - - edited 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 Authentication realm ' 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: '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
added a comment - - edited 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: '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
added a comment - 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
Joachim Herb
added a comment - 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 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
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
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
Tom Smith
added a comment - - edited 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
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
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
stephenconnolly suggested this might be a symptom of incorrect remoting of credentials, which already caused us a headache in SECURITY-144.
pianoroy your problem may or may not be related. TBD whether it can be reproduced from scratch. Probably deserves its own integration test here.
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
added a comment - 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.
Sam Hepenstal
added a comment - 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. 
Javier Arenales
added a comment - Jenkins 2.32.1
Subversion 2.7.1
Same issue. Is there any progress about it?
Javier Arenales
added a comment - Jenkins 2.32.1
Subversion 2.7.1
Same issue. Is there any progress about it? 
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.
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. 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.
My understanding is that JENKINS-32167 provides a better discussion, namely that the project must be configured to exactly match a realm.
Is it ok for everybody if we close this ticket as duplicate of JENKINS-32167 ?
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.
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. Well I was not proposing to close JENKINS-32167 just on the basis of improving error messages.
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.
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 . 
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?
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?
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.
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.
thomaskeller, I recommend you to upgrade to 2.5.4. Could you provide the job configuration?