This is occurring for us too – Ubuntu master, Windows slaves.

The first build of a clean workspace works. Any following builds fail on the revision check for any externs in the svn tree.

Still the same with https://jenkins.ci.cloudbees.com/job/plugins/job/subversion-plugin/341/org.jenkins-ci.plugins$subversion/ and jenkins 1.560

Still the same with subversion-plugin 2.3 and jenkins 1.562

I am getting the same using Jenkins ver. 1.562 and Subversion Plug-in 2.3

When I use the full URL it works ok, but when I use $SVN_TAG parameter with default trunk value I get:

ERROR: Failed to check repository revision for https://subversion.assembla.com/svn/???/trunk
org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/???/trunk failed
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
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:1020)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46)
at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461)
at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1267)
at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:78)
at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26)
at hudson.remoting.LocalChannel.call(LocalChannel.java:45)
at hudson.scm.SubversionSCM.compareRemoteRevisionWith(SubversionSCM.java:1452)
at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:357)
at hudson.scm.SCM.poll(SCM.java:374)
at hudson.model.AbstractProject._poll(AbstractProject.java:1427)
at hudson.model.AbstractProject.poll(AbstractProject.java:1330)
at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:466)
at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:495)
at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:701)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:694)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
... 34 more

seeing the same issue here as well

Has this ever worked? If the URL is modified by a parameter, how could polling work successfully?

After a discussion with Daniel Beck, we were able to find a setup where both variables and externals work both for polling and for the actual build for svn+ssh repositories:

Simple: use "Additional Credentials" with realm svn+ssh://SERVER_NAME

More complex:
see the code referenced in
https://issues.jenkins-ci.org/browse/JENKINS-21785?focusedCommentId=196730page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-196730

the command mentioned there seems not to work wor newer subversion clients.

Thanks. Closing.

solution checked with:
Jenkins 1.568
Credentials Plugin 1.14
SSH Credentials Plugin 1.7.1
Subversion Plug-in 2.4

Simple: for svn+ssh repos, use additional credentials with realm svn+ssh://SERVER_NAME

That 'Additional Credentials' is required for a default location does not make sense. It's only a workaround, the bug remains.

The solution does work but the logging needs improving to show which job is trying to access the external
We have several hundred jobs and knowing which one is causing the problem is nearly impossible to work out.

Guy: Workaround: fgrep on the master for the error message in the scm-polling.log files in job directories.

I've been experiencing the error with every checkout attempt, and it's persistent. Windows 7 master and slaves. Jenkins 1.565.2 and Subversion 2.4.3. I decided to upgrade from 1.561/2.0 after encountering some SVN external issues (J refusing to check out and then complaining things were missing).

Although it seems like a pure Subversion issue, downgrading Subversion plugin to 2.0 and 1.5.4 didn't help. Eventually, I upgraded it back to 2.4.3 and manually reconfigured all affected jobs in the above way. The error keeps recurring.

Edit:
I found out that Jenkins sometimes tries to connect to the SVN server without actually giving credentials. Here's from the svn server's connection log:

"
190.10.210.20 - jenkins [25/Sep/2014:15:09:06 +0200] ...
190.10.210.20 - jenkins [25/Sep/2014:15:09:06 +0200] ...
190.10.210.20 - - [25/Sep/2014:15:09:06 +0200] ...
190.10.210.20 - - [25/Sep/2014:15:09:06 +0200] ...

First two checkouts succeeded, last two didn't.

Seems no one else is getting this as a recurring issue? On some projects, the effect has become so bad that Jenkins is becoming unreliable for us to use (almost 50% of builds fail with this error). It seems like it got worse over time during the last three or four months, but I'm not sure the Jenkins upgrade was the trigger.

Hi,

don't know if this may help, but we had other issues after upgrading svn-plugin.
(handled somewhere here in another solved issue)

we solved our problems this way (don't remember details at the moment, but that's the direction we went):

• svn-plugin 2.3
• reworked jenkins configuration: added credentials in jenkins configuration for matching svn location (not that intuitive...)
• finally we added svn-credentials for native svn (svn simple!) in home of user running jenkins, on master and slave machines

this solved our issues, don't know if this might help you solving yours, but I hope it gives you some point to start with

Thanks a lot!

Actually, I upgraded Jenkins to 1.580 two days ago (because of the SVN trouble, I preferred to stick with the stable versions). And it seems that the problem is now "gone" ... or at least, in the state as described above, meaning it does occur but not recur, which seems heavenly after many many weeks of pain.

Just for the record, I logged all outgoing Jenkins connections to SVN, namely svnkit-network and hudson.scm.CredentialsSVNAuthenticationProviderImpl, but I couldn't find anything unusual.

Welp. Seems there is no explanation, but at least a solution!

Sorry, problem keeps coming back. Maybe it's because I'm using https?

Interesting aspect.

Java 7 seems to have some issues since those SSL-Updates of last days/weeks.
In some cases regarding SNI and SSL, especially when combined, Java 8 may be an option to try for master and slaves.

Another problem may be Windows updates, as some parts like smb/ad protocols get updated now and then and therefore some apache httpd modules might need an update for proper authentication/authorization against security realm/domain.

STEPS TO RESOLVE THIS ISSUE ON LINUX

====================================

REMOVE ALL SAVED CREDENTIALS ON YOUR LOCAL COMPUTER (NOT SERVER):
    rm -rf ~/.subversion/auth

ON YOUR LOCAL COMPUTER CHECKOUT REMOTE TRUNK:
    svn checkout https://your_svn_server:your_port/your_trunk

SVN WILL ASK FOR CREDENTIALS, SAVE THEM LOCALLY. THEY WILL APPEAR IN NEW FILE UNDER ~/.subversion/auth/svn.simple:
    ls ~/.subversion/auth/svn.simple

OPEN THIS FILE TO GET YOUR SERVER REALM:
    cat ~/.subversion/auth/svn.simple/ce8afc0996c10bf115408332b027d724

COPY YOUR SERVER REALM 2 LINES BELOW svn:realmstring, FOR EXAMPLE:
    svn:realmstring
    V 56
    <https://your_svn_server:your_port/your_trunk> Subversion Repositories            <--- THIS ONE IS YOUR SERVER REALM

CONFIGURE YOU JENKINS JOB -> PRESS "ADD ADDITIONAL CREDENTIALS":
    SET "Realm" TO COPIED STRING, I.E: <https://your_svn_server:your_port/your_trunk> Subversion Repositories
    PROVIDE VALID "Credentials"

VOILA! 
HOPE THIS HELPS.

... which is basically what the comment from 27/Jun/14 8:01 AM states (JENKINS-21785 is the original 'Additional Credentials' issue).

It is still there in 2015. Jenkins version 1594, Credentials Plugin 1.20, subversion plugin 2.5
The error message is new: It is now
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
Additional credentials as suggested above have been added. And there is the question why they are needed in the first place if the externals are in the same repository (realm).

For me this is a blocker. It makes Jenkins the wrong tool to use with Subversion-Externals.

Hans: Please provide substantially more information on how to reproduce this issue. How is the job configured? How is the SVN server configured? Did it work before, and if so, what changed? Does it work when downgrading to Subversion plugin 2.4.x?

Daniel: I have tried it with three different Jenkins configurations all running on Linux servers against the same repository (Server version Subversion 1.6.11 (r934486)). It is managed by enterprise it, so I can not do anything about it. (Its a global Bank, so upgrading software is extremely conservative)
However it works on a very old installation of Jenkins, so the server does not seem to be the problem:
1. Jenkins 1.549, Credentials plugin 1.9.4, Subversion Plugin 1.54, Subversion Workspace format 1.6
It fails after upgrading to newer versions of Jenkins:
2. Jenkins version 1594, Credentials Plugin 1.20, subversion plugin 2.5, Workspace format 1.6
3. Jenkins 1.596, Credentials Plugin 1.19, subversion plugin 2.4.5, Workspace format 1.7

To me it is the credentials plugin (or its use by the subversion plugin), that seems most suspicious. The upgrade made it a lot more complicated in a way, that we neither need nor want.

Also Idea configured to use svnkit does not have any problems with the externals setup from my local windows development machine.

This is what our subversion configuration with credentials looks like. Maybe something is wrong there?

I am also having the same problem that Hans notes, and it seems mostly to revolve around the svn externals. We use a lot of them, and it really becomes an issue.

I also had it working with an older version of Jenkins and plugins, I moved to a new server and this is coming up all the time.

EDIT: After adding the alternate credentials to all my jobs,this is not happening anymore.

I have the same problem on my projects with svn:externals (sometimes)

The Subversion plugin 2.5 completely broke polling for me. Just polling not checkout. Although there also have been new sporadic problems with externals on checkout.
I am using variables in my URLs. The values are defined as Environment variables in the system configuration.

org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.

Subversion: 2.5
Jenkins: 1.580.2
Credentials: 1.21
Workspace: 1.8 and 1.7

Reverting back to Subversion 1.4.5 solved the problem.

As Hans and Eric have said, we're also receiving this on Externals during builds: intermittently and which external causes this can vary. We are attempting to switch to Jenkins now and use a lot of externals, so unable to define if working before.

We've seen a job succeed and then the downstream project fail with this exception as well. Downstream may or may not succeed, if it fails it may or may not be due to the same external as the upstream. Very odd to see it work sometimes and not others.

This occurs with and without Additional Credentials being set.

Subversion: 2.5
Jenkins: 1.596
Credentials: 1.21
Workspace: 1.8

hudson.util.IOException2: revision check failed on https://svn/path/here
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:196)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:137)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1265)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
at hudson.model.Run.execute(Run.java:1759)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
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

Same here with Subversion 2.5, Working Copy 1.7 and Jenkins 1.598.

svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.

Going back to 2.4.5 and it worked again.

We have the same problem. Sometimes it works, sometimes it fails. Does anybody know if there is any action here?

I have an issue only with lastest Subversion plugin 2.5 version.
Previos 2.4.5 works stable. You can install it.

We're also seeing this problem after upgrading to 2.5. Had to downgrade to 2.4.5.

We are having the same troubles here.

E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.

environment: Jenkins 1.598 running on Windows Server 2012 R2 Standard, 64 bit
relevant plugins: Subversion 2.5; Credentials 1.22

After downgrading to subversion plugin 2.4.5 polling works as always.

Does anyone have a workaround for this? About 20% of our builds fail because of this. Running the build again and everything works.

For me this is a random failure mode. Polling for Changes is succesfull about 90% of the builds.

However: we have a few Timed jobs which do a complete clean checkout every night.
The checkout succeeds, but the following building of the changelog fails.

Jenkins 1.612 , subversion 2.5, credentials 1.22
svn server is accessed via https with username + password

Started by timer
[Checkout log]
At revision 6
no change for [module2] since the previous build
no change for [^\external1] since the previous build
no change for [^\external2] since the previous build
hudson.util.IOException2: revision check failed on [^\external3]
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:196)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:137)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
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:1744)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:374)
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

Hi, we have a similar problem with the latest Subversion plugin 2.5 version.
We have a project which has svn:external dependency. If we do a commit to this external and then executed the job, the svn update is failed. This problem is only for the first execution of the job after commit to the external, next repeating of the job is successful.

We have received this stacktrace:
hudson.util.IOException2: revision check failed on http://externalUrl/project.Foo/trunk/xxx/
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:196)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:137)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1270)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
at hudson.model.Run.execute(Run.java:1718)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
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)

Suppose it because only first time you really getting externals. After you will get them (and got error) if them was changed.

I've enabled logging for hudson.scm (level all):
When I combine this with the build log (same machine, so no master/client time issues):

(svnlog) 07:58:45: attempting auth for .../cobra/trunk [caused by polling svn]
(build)  07:58:45: Building in WorkSpace ...
(build)  07:58:46: Updating .../cobra/trunk
(svnlog) 07:58:47: attempting auth for .../cobra/trunk [caused by svn update] 
(build)    ... svn update 
(build)    ... fetching externals
(svnlog) 07:59:19: attempting auth for .../cobra/trunk [caused by building of changelog]
(build)  07:59:20: No Change for <external1> since last build
(svnlog) 07:59:20: attempting auth for <external2>  [caused by building of changelog (?)]
(build)  07:59:20: hudson.util.IOException2: revision check failed on <external2>{quote}

<external2> is in the same repositiory as the project being built.
The url for external2 has been configured in add extra credentials.
the realm for cobra/trunk/ and external2 in the log file is both the same (and correct).

Any suggestions on how to get (or add) extra logging to troubleshoot this issue?

Hi Guys,
had the same problems since my update from Subversion Plugin 2.4.latest to 2.5
As you can see in the changelog, in version 2.5 SVNVersion is changed to SVN1.8
As far as I have SVN 1.7 installed on my machines I went back to Subversion Plugin 2.4 and everything worked fine again.
Hope this helps you

Rebuilt svn plugin with svnkit 1.8.10. No change.
Created a test build which did a complete checkout every 10 minutes.
Checkout always succeeds (114x), building the Changelog sometimes fails (1x of the 3 changes to this particular project).

Same - encountered the issue with 2.5, rolled back to 2.4.5 and it was gone. (Jenkins 1.612)

A scenario to reproduce:
SVN repository hosted via https (assume https://localhost/svn/)
SVN authentification via username/password.
(other combinations have not been tested)

In the Repository are two projects:
projecta/trunk and projectb/trunk.
projecta/trunk has an svn:externals property projb=^/projectb/trunk.

Jenkins project points to https://localhost/svn/projecta/trunk.
To exclude faults additional credentials have been added for https://localhost/svn/projectb/trunk.

When a user commits only to projecta all is well.

When a user commits to projectb, retrieving of the changelog fails.
when polling is used to trigger, no build is started.
When a timed build is used, the build fails because the change log can not be made.

logging shows that in CredentialsSVNAuthenticationProviderImpl.requestClientAuthentication
the 'List<SVNAuthentication> authentications' remains empty.

renea thank you for that test case. I will see if I can reproduce the issue from your description

It happens occasionally with my installation. However sometimes it decides to checkout fresh copy when reverting fails (I only guess this is the case why some of the reverts fails, no log actually tells me). Which wouldn't bother me too much, if it wasn't for our broken cache server data, that caused my installation of Jenkins absolutely impotent. This week my weekly report will look utterly ugly because of these two things happening just together during week before new release of our product.
I hope this will get fixed soon.

renea So I was able to get the issue you describe by following your test case... but it would appear - at least from my testing - that the issue is really that the additional credentials have not been provided.

As soon as I added additional credentials with the correct realm the polling started to work and the issue disappeared.

The key thing to remember is that svn:externals can be used to leverage the read-access that Jenkins has against the repository where you might have lesser access.

So if I have write access to projecta but no access to projectc, Jenkins may well be locked down so I can only see the projecta job, but by committing an svn:externals pointing at projectc and modifying the build script to tar-gz the contents of that external and sftp it to my computer I can effectively bypass the security permissions on the subversion repository.

The hard part is getting the realm correct, so for example if you run:

$ svn info https://svn.apache.org/repos/private
Authentication realm: <https://svn.apache.org:443> ASF Members
...

Then the realm you want to specify in additional credentials is: <https://svn.apache.org:443> ASF Members

Similarly if subversion is running via svnserve you might see

$ svn info svn://localhost
Authentication realm: <svn://localhost:3690> cd90323c-3140-4208-9a36-a9a21ef8b680

And again the realm you need to specify in the additional credentials would be: <svn://localhost:3690> cd90323c-3140-4208-9a36-a9a21ef8b680

Can you check whether you actually have specified the realm correctly?

stephenconnolly Okay, this works for me.
I had specified the urls of the externals, not the realm.

From all the test cases presented so far, this is a case of the incorrect realm or no realm being configured.

JENKINS-21785 discussed the externals issue before in great detail. We should limit this one specifically to variables in the URL.

How can you display the realm for a repository? For me with svn 1.8.13 on OSX I get this:

$ svn info
Path: .
Working Copy Root Path: /Users/ari/svn/apache-foundation
URL: https://svn.apache.org/repos/private/foundation
Relative URL: ^/foundation
Repository Root: https://svn.apache.org/repos/private
Repository UUID: 694d45b4-53eb-0310-9336-ddcd440d954d
Revision: 59701
Node Kind: directory
Schedule: normal
Last Changed Author: clr
Last Changed Rev: 59700
Last Changed Date: 2015-06-25 10:54:00 +1000 (Thu, 25 Jun 2015)

which part is the realm that Jenkins is wanting?

I don't understand why its not enough to have credentials already setup in ~/.subversion/auth/... and in the global credentials section in jenkins.
I don't want to provide additional credentials to every project setup because in the 2.4 plugin its not needed and it works there. So why its needed now and why does it not use the global configured svn credentials for the server - i don't have different realms or servers in use because all externals are pointing to the same server but may use a different repository (although it may be the same too) - i don't use variables in repository urls. It would be fine to use the already known credentials because they are identical for the complete server - how to configure that?

Same for me. My svn:externals also point to the same server. Thus the credentials and also the realm of the svn:externals and the main repository are in my case (and probably in 99% of hudson users) identical. Since hudson knows already the credentials of the server I wonder why it does not take the same credentials for the externals (which have exactly the same realm). Entering the credentials twice might be a workaround. However, it looks for me like a bug and since version 2.4 was capable of handling it correctly it's furthermore a regression.

Reopened to discuss the possible regression vs. 2.4 plugin version.

Created JENKINS-29079 to discuss possible improvements of the configuration.

kasparek Hello, Do you think that this ticket is related to JENKINS-23007? Maybe duplicated?

Yes, seems like the same problem with variables and repo URL