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

kasparek, Hello, Did you see that JENKINS-23007 was resolved recently?

Indeed, that should be ok for the case related to variables in url but does this fix also the case of repos with externals ?

splashnenen, Nothing releated with externals have been included in Subversion Plugin 2.5.2. But if you file an issue with a detailed description including a step by step process in order to reproduce the bug, I'd like to help you.

usecase is this one :

• main configured svn repository is : http://myrepo/example/main_product
• credentials for this repository are set using the 'credentials plugin'
• there are externals which are on the same repository (chechbox 'ignore externals' is obviously unchecked)

The jobs polls the repo and update fails on external if those conditions are verified :
1. there are modifications on both main repository and this external
2. this external is referenced twice

All externals passed ok, the one which is not up to date updates successfully then fails on second check with error "Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled."

(See attached 'external error' file)

splashnenen Did you define Additional Credentials and make sure the authentication realm is the exact string used by your SVN server?

splashnenen, I'll try to reproduce this scenario. danielbeck have pointed something important.

I didn't define addintional credentials as the repository is the same than the main one in configuration.
And according to the screenshot, you may check that update is well done on external at first try, so credentials seems to be well considered.
Error pops at second try only, the error message may in fact mask the real problem.

I didn't define addintional credentials as the repository is the same than the main one in configuration.

That's not how it works. See e.g. https://issues.jenkins-ci.org/browse/JENKINS-21785?focusedCommentId=196363&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-196363

Thanks for this information but it doesn't match with the fact that update is well done for external at first check, meaning that credentials are well used, no ? It's only at second check that it fails. Maybe we could check if Manuel is able to reproduce.

it doesn't match with the fact that update is well done for external at first check

According to Stephen Connolly, the reason for this is connection reuse/caching of some kind in SVNKit.

Hello, checked the current behavior - the polling with variables seems to work as far as SVN is concerned now. The remaining problem is, that even if there is default value for the variable to be used for polling and build, the last manually used value (e.g. SVN branch for our case) is used instead of default value (trunk).

e.g. This build is parameterized:
name: SVN_SUBDIR
repo url: svn+ssh://xxx/svn/PROJECT
Default value: trunk

String Parameter:
name: REVISION
default value: HEAD

Source Code Management:
repo url: svn+ssh://xxx/svn/PROJECT/${SVN_SUBDIR}@${REVISION}

if I request the build of branch-ABC, then automatic polling will try to check this branch instead of trunk.

Would you like me to fire this as new independent issue here? (not talking about SVN external for now)

Bye

I have added credentials for each external (although it's on the same repository) and i still have the problem : the first update of external is ok then checking if this same external is up to date fails with error (as shown in 'external error.png' screenshot).
It seems there is another thing on that, could you have a look to double check ?
Thanks a lot

aaubert, I'll have to configure a similar scenario using externals.

The issue still present on plugin 2.5.2. Have to use 2.4.5.

Hi kasparek,

Please check my proposal in JENKINS-19560 and related comments in JENKINS-14155

Both relate to handling the "DEFAULT" value and "automatic branch selection_.

I second aaubert comment, this is still not fixed and still breaks for me with 2.5.3 - while 2.4.5 is working.
Credentials are selected in the configuration and it does work while checking for updates on the checkout pointing to externals. But then looking for changes on those externals it fails - but both are in the same repository.
Look at the trace below - it does successfully fetch changes from

https://svn.local.domain/svnrepos/dev/util/branches/1.8

but fails later in the same run trying to look for changes on

https://svn.local.domain/svnrepos/dev/util/branches/1.8

- how could this be, it can fetch data from there but is unable to check the revision later on - seems like a bug to me and reads like aaubert problem.

Updating https://svn.local.domain/svnrepos/dev/releases-hooks/trunk/usr-1.8 at revision '2015-09-16T13:05:00.748 +0200'
Fetching 'https://svn.local.domain/svnrepos/dev/util/branches/1.8' at -1 into '/home/jenkins/Development/src/usr-1.8/util'
U         util/src/java/de/sf/util/MailSender.java
At revision 52046
Fetching 'https://svn.local.domain/svnrepos/dev/usr/branches/1.8' at -1 into '/home/jenkins/Development/src/usr-1.8/usr'
At revision 52046
At revision 52046
no change for https://svn.local.domain/svnrepos/dev/releases-hooks/trunk/usr-1.8 since the previous build
hudson.util.IOException2: revision check failed on https://svn.local.domain/svnrepos/dev/util/branches/1.8
	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:1277)
	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:408)
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

FYI: I don't use any variables in URLs, just externals are used.

tkrah Thanks so much. Your feedback is awesome. I can work on this bug with your information.

tkrah

Environment

• Jenkins ver. 1.568 (minimum version required by Subversion Plugin)
• Subversion Plugin 2.5.3
• svnserve, version 1.6.17 (r1128011)
• 1 repository with name: external1 (requires credentials)
• 1 repository with name: JENKINS-22542 (requires the same credentials) and its svn:externals property:

  pegaso:JENKINS-22542 recena$ svn propget svn:externals
  svn://192.168.1.106/external1 external1
  

First build (checkout process)

Started by user anonymous
[EnvInject] - Loading node environment variables.
Building in workspace /Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542
Checking out a fresh workspace because there's no workspace at /Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542
Cleaning local Directory .
Checking out svn://192.168.1.106/JENKINS-22542 at revision '2015-09-17T00:39:46.217 +0200'
 U        .
Fetching 'svn://192.168.1.106/external1' at -1 into '/Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542/external1'
A         external1/file1.txt
 U        external1
At revision 3
At revision 4
no change for svn://192.168.1.106/JENKINS-22542 since the previous build
no change for svn://192.168.1.106/external1 since the previous build
Finished: SUCCESS

Second build (update process)

Started by user anonymous
[EnvInject] - Loading node environment variables.
Building in workspace /Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542
Updating svn://192.168.1.106/JENKINS-22542 at revision '2015-09-17T00:40:18.385 +0200'
Fetching 'svn://192.168.1.106/external1' at -1 into '/Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542/external1'
At revision 3
At revision 4
no change for svn://192.168.1.106/JENKINS-22542 since the previous build
no change for svn://192.168.1.106/external1 since the previous build
Finished: SUCCESS

SCM Polling

Started on Sep 17, 2015 1:05:00 AM
Received SCM poll call on master for JENKINS-22542 on Sep 17, 2015 1:05:00 AM
svn://192.168.1.106/JENKINS-22542 is at revision 4
svn://192.168.1.106/external1 is at revision 3
Done. Took 33 ms
No changes

In Jenkins, Subversion Workspace Version configured to 1.8

I could not reproduce the bug. I'll try with more configurations. Any idea is welcome.

tkrah Are you sure the realm is specified correctly?
See also https://issues.jenkins-ci.org/browse/JENKINS-22542?focusedCommentId=230849 by stephen connolly.

The Realm is NOT h..ps://svn.local.domain/svnrepos/dev/util ,
but should look more like "<h..ps://svn.local.comain> svn users".

When you create a new set of credentials the realm is used as the description.

Hi recena. Thanks for these tests.
To me, your case is correct. To reproduce now, you may try a third run :

• use 'credentials plugin' and set credentials as user/password in the credentials global configuration
• configure your job to use this credential
• make changes in your 'external1' so that the build will update this external
• run this build and you should have the problem which happens during last phase of summary displaying 'No change for...'
  Please let me know if you need any further information.

renea You are speaking about the Realm i can specify when using Additional Credentials. However i did not even considered to configure additional ones because i don't need them. The external points to the same repository, i am just using global credentials and configured to job to use them. I can't specify a Realm in the global credentials - i've just configured there my URI spec to be https, the hostname to be svn.local.domain and the path part to be /svnrepos/** .
Looking at the help of Description part when creating new credentials it reads:

A description for the domain, not used by Jenkins itself.

So something wrong there if i need to add a Realm to a description field which is not used.

Hi aaubert,

• I used credentials-plugin to set my credentials.
• I configured my job to use this credentials.

I'm going to try your third and fourth step.

recena

I got it instantly failing with this recipe:

1. create a new svn repository /tmp/JENKINS-22542 with svnadmin create and configure svnserve.conf, use default passwd stuff.
2. start it svnserve -d --foreground -r /tmp/JENKINS-22542
3. go to /tmp/import directory and create 3 dirs there: root, link1, link2
4. do a svn import for for those 3
5. go to /tmp/checkout and do a svn checkout svn://localhost:3690/
6. now create a file in link1 directory which contains:

   link2 svn://localhost:3690/link2
   link1 svn://localhost:3690/link1
   

1. now cd to root directory and do a svn propset svn:externals --file ../link1/test .
2. do a svn ci . on root

1. Now configure a freestyle build job which uses current credentials plugin and subversion plugin and point configuration to:
   svn://localhost:3690/root

1. Add global credentials there for harry/harryssecret using the passwd stuff from svnserve. Run it - works.
2. Now do a "svn add test" in the link1 directory and commit it.
3. Now trigger a second build - it fetches the changed file but fails on calcChangeLog(..)
4. Run it again - works now again.
5. Edit the "test" file and switch lines and commit the change.
6. Trigger the build again - failing again.

tkrah I was under the same assumption. But as of 2.5.0 there is a regression (in my eyes) that whenever you use externals you need to specify additional (but the same) credentials.
These credentials are only used for changelog calculations.

Can you try with additional credentials specified?
And yes, the description field for credentials is not used by jenkins. But the value which is automatically filled in there when you create the credentials matches the realm name.

renea

Gotcha - that's interesting. If i specify additional ones with the Realm although its the "same" it does work. But that's imho clearly a regression - i second your opinion. It works without that in 2.4.5. I would understand that you need additional ones if the external is pointing to another repository which needs different credentials than the already configured ones on the module. But that is not the case here. How to tell people that they need to specify the same credentials twice for the same repository - i am not convinced that this is the way it should be. From a logical point of view its seems illogical to me todo that - i won't ever come to this "workaround" or solution because its called "Additional Credentials". It should imho work like in 2.4.5 with the ones already set.

renea, tkrah

I agree, it is illogical (and an UX issue). I'll solve it this night.

recena to save you some time searching:

I looked earlier this year but haven't had the time to really dive in, fix and test.
I came to the conclusion that the fault is likely in SubversionChangeLoguilder.Java:128

        ISVNAuthenticationProvider authProvider =
                CredentialsSVNAuthenticationProviderImpl
                        .createAuthenticationProvider(build.getParent(), scm, null);

The null should (I think) be the module location, but I'm not sure how situation with different modules including externals are to be handled.

However i did not even considered to configure additional ones because i don't need them. The external points to the same repository, i am just using global credentials and configured to job to use them.

You'll get nowhere by refusing to do what everyone tells you is the solution to this issue. That additional credentials are needed has been posted in numerous comments to this issue for over a year. I realize that having to do this is a bit annoying (been there, reconfigured 400 jobs), but for now the solution for externals and variables is to use Additional Credentials.

It works without that in 2.4.5.

I think It was always supposed to fail as a security measure as stephenconnolly explained in a comment above. He once told me that there's an issue with SVNKit reusing the same connection to download externals when it should not. Since 2.5 updated SVNKit to a new version, it's likely some part of that behavior was changed there.

I don't refuse anything - i just try to understand why this is failing now and if there is some good reason - at least the changelog for subversion should mark a breaking change here so that users know about.
Imho its just not logical - its called Additional - not "External Credentials" - why can't Jenkins just provide the same configured gobal credentials automatically in that case?
Another thing which is confusing - if this is a security measure - its imho failing, because it does fetch the external changes but does only fail on Changelog generation - if its for security, it should fail already fetching the external stuff but it fails only for changelog stuff - why is this difference, i would expect to fail completly and not to be able to fetch the external stuff and failing later on the not so important changelog (in case of security terms)? I am just trying to understand why this should be the "official" solution to that problem - it seems not logical and at least until now i did not read something why Jenkins can't provide a better solution to that case than doubling all credentials configuration.

Another Idea - if this is the proposed solution - why keeping the first credentials option at all? Just remove it and rename "Additional Credentials" to "Credentials" and users are forced to set some Credentials there. They won't do it twice and i would work out-of-the box, how about that?

Another thing which is confusing - if this is a security measure - its imho failing

Please let me repeat:

… there's an issue with SVNKit reusing the same connection to download externals when it should not. Since 2.5 updated SVNKit to a new version, it's likely some part of that behavior was changed there.

I'm not 100% sure this is the cause here, but it looks like a possible culprit.

If there is an issue there - can you link the upstream bugreport from SVNKit in this ticket please?

tkrah

I did more tests with this environment and everything is working fine.

I'm going to try with your environment, svn:externals against the same repository.

hallelujah! It seems I found the bug!

@Manuel: We are eager to hear the story + when the fix will come out...

@ Manuel Eagerly awaiting your fix. Since we use LTS releases, we ask for a new LTS bugfix release asap.

bangalore AFAIK, LTS policy only applies to Jenkins CORE.

Yes, SVN plugin is independent from Jenkins core since 1.4xx (I don't recall the exact version).
You can just update the plugin when it gets released.

The new version will be bundled into Jenkins core in 1.625.2, I suppose

oleg_nenashev SVN plugin has been detached from core since 1.310. And we're still bundling 1.54 due to the change to credential storage in Subversion 2.0.

danielbeck but, Would it be possible to update Subversion Plugin in the next LTS?

You can update any plugin to any version compatible with the release you're running. For Subversion plugin, this is 1.568 and newer.

danielbeck, I meant here (bundled).

Prove that an established instance's update to 2.x will go smoothly. We've so far not done that due to concerns that credential migration is a breaking change. Given how Stephen Connolly tightened security on externals, it's almost certainly breaking existing setups for users that are still on 1.x.

recena, if you have a minute, please tell us what the bug was! There seem to be a number of people, including me, waiting eagerly to know what was the cause of our troubles

Hi,

I said I had found the bug but if you configure the additional credentials in a right way, everything works fine.

In my case, I configured a credentials (in additional credentials) using this realm <svn://192.168.1.106:3690> example real. It is very important that the realm is written rightly. Here you can see two console outputs (SCM Polling):

Started on Sep 22, 2015 10:24:00 PM
Received SCM poll call on master for JENKINS-22542 on Sep 22, 2015 10:24:00 PM
svn://192.168.1.106/JENKINS-22542 is at revision 7
svn://192.168.1.106/external1 is at revision 4
svn://192.168.1.106/external2 is at revision 1
Done. Took 0.18 sec
No changes

Started on Sep 22, 2015 10:26:00 PM
Received SCM poll call on master for JENKINS-22542 on Sep 22, 2015 10:26:00 PM
svn://192.168.1.106/JENKINS-22542 is at revision 8
  (changed from 7)
svn://192.168.1.106/external1 is at revision 4
svn://192.168.1.106/external2 is at revision 1
Done. Took 24 ms
Changes found

Regards,

Hi,

can you please tell me how to configure the additional credentials when the Subversion server is using a HTTPS connection because

<https://svn/repo> Subversion Repository

didn't seem to work.

Regards,
Philip

recena - so just for understanding - is this default behaviour going to be fixed to use the configured default credentials when searching for additional credentials and nothing extra is configured to get this one working - or whats the proposed solution in an UX friendly way?

pschoemig Please read JENKINS-21785.

pschoemig, you have to use realm. It is a string. To know this value, I followed these basic steps:

1. Remove my .subversion folder (in my local development environment)
2. Checkout the source code. This was the output

pegaso:temp recena$ svn co https://subversion.assembla.com/svn/jenkins-26318/
Error validating server certificate for 'https://subversion.assembla.com:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: *.assembla.com
 - Valid: from Wed, 16 Apr 2014 13:31:17 GMT until Thu, 24 Mar 2016 19:30:40 GMT
 - Issuer: http://certs.godaddy.com/repository/, GoDaddy.com, Inc., Scottsdale, Arizona, US
 - Fingerprint: ec:9f:9d:b2:39:e1:34:81:7b:27:f6:51:30:8b:ac:41:5b:62:09:19
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Authentication realm: <https://subversion.assembla.com:443> Assembla Restricted Area
Password for 'recena':

You can see my realm: <https://subversion.assembla.com:443> Assembla Restricted Area

Regards,

tkrah, the main goal here is to verify that there is no bug. If we want to improve this, we should file a new ticket for that.

recena depends on the point of view of the person. To me (and like read above to others too) this one is a regression to 2.4.x plugin because you need to specify "Additional Credentials" for the "same" repository. This is - you agreed upon - illogical todo. So to me this is a Bug - i can of cause just open a new ticket which referes to this ticket which has a known workaround and the UX issue, which is caused by this workaround, is tracked at this new ticket - e.g. getting rid of the first credentials dialog and just have the "Additional" one like proposed.
Opinions?

tkrah, recena , there is already a ticket: JENKINS-29079 .

tkrah, I think it is more interesting if we close this ticket and continue working on JENKINS-29079.

In this ticket there is enough information to clarify this UX issue.

If kasparek agree, I propose to close this ticket.