Details
-
Bug
-
Status: Reopened (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
-
Windows Server 2008 R2,
Jenkins 1.599
Description
We're using username and password over HTTP as authentication to the svn server and the Jenkins service is running as the same user.
Recently we upgraded the subversion plugin to v2.5 from v2.4.5 and this caused svn authentication to fail with the following error:
svn: E200015: authentication cancelled
Diving deeper into the cause of this revealed that Jenkins no longer tries to login to the svn server using HTTP clear text authorization (don't know the real name for this) but now tries to use NTLMSSP. Jenkins seems to use the correct username using NTLMSSP but the authentication fails.
Attachments
Issue Links
- is duplicated by
-
JENKINS-26158 Active Directory authentication for Subversion plugin fails
-
- Resolved
-
-
JENKINS-26370 Subversion Plugin 2.5 skips some externals resulting in partial checkout
-
- Resolved
-
-
JENKINS-26440 svn: E200015: authentication cancelled (subversion plugin 2.5)
-
- Resolved
-
- is related to
-
JENKINS-27977 NullPointer & authentication cancelled occure immediately on SVN checkout
-
- Closed
-
Activity
Hi,
Have you tried reordering the authentication schemes?
Add this to the startup options in jenkins.xml:
-Dsvnkit.http.methods=Basic,NTLM,Negotiate,Digest
This means that Basic authentication will be tried first.
/ Björn
Adding -Dsvnkit.http.methods=Basic,NTLM,Negotiate,Digest to jenkins.xml fixes the issue.
Now I'm just wondering:
Why is there a line saying lib.svnkit.http.methods Digest,Basic,NTLM,Negotiate when I go to JENKINS_HOST/systemInfo
even though I've added the -Dsvnkit.http.methods=Basic,NTLM,Negotiate,Digest to jenkins.xml?
lib.svnkit.http.methods=Digest,Basic,NTLM,Negotiate
svnkit.http.methods=Basic,NTLM,Negotiate,Digest
The first part, lib. subtle difference, and I don't know what the difference is, actually. Maybe someone else has the answer?
/ Björn
Well, it doesn't seem to be a workaround in all cases. We have several slaves running and the workaround only worked on some of them.
The rest throw this exception:
org.tmatesoft.svn.core.SVNCancelException: svn: E200015: authentication cancelled 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.getNextAuthentication(DefaultSVNAuthenticationManager.java:215) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:685) 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.getRepositoryUUID(DAVRepository.java:143) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) 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.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath.act(FilePath.java:989) at hudson.FilePath.act(FilePath.java:967) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833) 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:1750) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) FATAL: null java.lang.NullPointerException at java.util.ArrayList.addAll(Unknown Source) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833) 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:1750) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240)
I've reopened the issue because the workaround doesn't work in all cases.
I don't know why the above workaround only works on some slaves but by adding -Dsvnkit.http.methods=Basic,NTLM,Negotiate,Digest to jenkins-slave.xml on the rest of the slaves seems to work.
This is really annoying since we have a lot of slaves.
It would be a little easier if I could set the property from the Jenkins master but JENKINS-9911 prevents me from doing so.
I'm not exactly sure how this works but don't I risk Jenkins overwriting jenkins-slave.xml at some point if I add the property to jenkins-slave.xml manually?
Could we expect a better handling of the situation at least ?
(A fix of the NullPointer, that should never be thrown in production ?)
Calls to svnkit.http.methods are only made in "SubversionSCM.java" from what I can tell.
The editor made no notes as to why they would have changed a call like:
System.setProperty("svnkit.http.methods","Digest,Basic,NTLM,Negotiate"); // as it was in 2.4.5
to
System.setProperty("lib.svnkit.http.methods","Digest,Basic,NTLM,Negotiate");// as it is now in 2.5
Maybe someone can find the reason in the check-in that changed the file.
Changing all calls to "lib.svnkit.http.methods" back to "svnkit.http.methods" in this file and recompiling the* .hpi *image seems to allow me to check out my repositories without issues.
I'm having this problem in Jenkins 1.614 on Ubuntu 14.04 LTS Server.
On Ubuntu server - there does not appear to be any jenkins.xml - I have config.xml in /usr/lib/jenkins, but since there is not tree/element information about where to put the configuration string, I can't see how to update the configurations to make this work.
I've found a couple of other bugs and discussions pointing to JAVA_ARGS and JENKINS_ARGS in /etc/default/jenkins - and have added the parameter as above, but it still is not working.
willste Interesting. https://github.com/jenkinsci/subversion-plugin/commit/966d051476cfbe880c6a820570ab370b3ec6da4d#commitcomment-11542216
Code changed in jenkins
User: christ66
Path:
src/main/java/hudson/scm/DirAwareSVNXMLLogHandler.java
src/main/java/hudson/scm/SubversionChangeLogBuilder.java
src/main/java/hudson/scm/SubversionEventHandlerImpl.java
src/main/java/hudson/scm/SubversionSCM.java
src/main/java/hudson/scm/UserProvidedCredential.java
src/main/java/hudson/scm/subversion/UpdateUpdater.java
src/test/java/hudson/scm/SubversionSCMTest.java
http://jenkins-ci.org/commit/subversion-plugin/2e6f2940b5f561b2377a72ddbe1fd9d7c0f15b52
Log:
JENKINS-27084 Revert system property changes.
Code changed in jenkins
User: Steven Christou
Path:
src/main/java/hudson/scm/DirAwareSVNXMLLogHandler.java
src/main/java/hudson/scm/SubversionChangeLogBuilder.java
src/main/java/hudson/scm/SubversionEventHandlerImpl.java
src/main/java/hudson/scm/SubversionSCM.java
src/main/java/hudson/scm/UserProvidedCredential.java
src/main/java/hudson/scm/subversion/UpdateUpdater.java
src/test/java/hudson/scm/SubversionSCMTest.java
http://jenkins-ci.org/commit/subversion-plugin/ad260ce0084b1e9fef9eae6ac14653bd1f5bcd74
Log:
Merge pull request #117 from christ66/JENKINS-27084
[FIXED JENKINS-27084] Revert system property change
Compare: https://github.com/jenkinsci/subversion-plugin/compare/a67ae6efb352...ad260ce0084b
Hi,
This bug is marked as delivered in the changelog for version 2.5.1 of the svn plugin: https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin
Can anyone confirm that this does indeed fix the issue for them - because I've tried installing Jenkins 1.623 with Subversion plugin 2.5.1 on a clean environment and I hit exactly this issue when I checkout externals (Windows master and Windows/Linux slaves). Either the fix is not actually contained within the plugin as listed, or I have encountered a different but visually similar problem.
I'm not currently blocked because I've reverted to the default svn plugin for now (1.5.4) and this functions perfectly in every way except for svn 1.8 support.
I am also still having an issue with svn: E200015: authentication cancelled error. RedHat Linux, Using Jenkins 1.624, Subversion plug-in 2.5.1, Subversion Client 1.8 with plain text passwords.
Steps I have taken:
changed svnkit.http.methods to Basic,NTLM,Negotiate,Digest
deleted my .subversion directory
nyoung02 I'd like to help in order to solve this bug.
- Environment: Jenkins 1.623 + Subversion Plugin 2.5.1 running on Windows. (It seems it is happening on RedHat)
- Add a FreeStyle Job
- Configure a Subversion repository (auth required)
- etc...
Please, Could you help me to complete this step by step process?
I tried to reproduce the error on a simple SVN configuration and repository, but I cannot reproduce for this simple case. The repository that fails on is a different svn server configuration with a more complicated repository structure. I will try to get a copy of the svn server configuration to try and reproduce the bug, if that doesn't work I will introduce some of the complexities such as externals and symbolic links to the repository. This may be one of those edge cases that are hard to narrow down.
mushadow This would be great! I want to know if your bug is related with this ticket or not. Thanks a lot for your time.
Found out the problem. It is more of a missed dependency on my part, but the error message is still the same and doesn't point to my missed dependency.
- Install Jenkins 1.624 with Subversion plugin 2.5.1 set to checkout version 1.8
- Create svn repo1, with an external to repo2 with a different user name. (see attached script below for repo setup)
- Create Freestyle Job, add svn server path to repo1 and only supply the repo1 credentials, uncheck ignore externals
- Run job to produce svn: E200015: authentication cancelled
Checking out svn://localhost/tmp/svn_test/repo1/project at revision '2015-08-20T10:16:44.101 -0500' ERROR: Failed to check out svn://localhost/tmp/svn_test/repo1/project org.tmatesoft.svn.core.SVNCancelException: svn: E200015: authentication cancelled 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.getNextAuthentication(DefaultSVNAuthenticationManager.java:215) at org.tmatesoft.svn.core.internal.io.svn.sasl.SVNSaslAuthenticator.createSaslClient(SVNSaslAuthenticator.java:310) at org.tmatesoft.svn.core.internal.io.svn.sasl.SVNSaslAuthenticator.authenticate(SVNSaslAuthenticator.java:140) at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.authenticate(SVNConnection.java:198) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.authenticate(SVNRepositoryImpl.java:1276) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1254) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLatestRevision(SVNRepositoryImpl.java:169) 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.ng.SvnNgAbstractUpdate.handleExternalItemChange(SvnNgAbstractUpdate.java:347) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.handleExternalsChange(SvnNgAbstractUpdate.java:310) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.handleExternals(SvnNgAbstractUpdate.java:246) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:224) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:72) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:802) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) 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 hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:115) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2691) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) 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:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Thread.java:724) AU test.txt U . FATAL: null java.lang.NullPointerException at java.util.ArrayList.addAll(ArrayList.java:530) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833) 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:381) Started calculate disk usage of build Finished Calculation of disk usage of build in 0 seconds Started calculate disk usage of workspace Finished Calculation of disk usage of workspace in 0 seconds Finished: FAILURE
So the obvious problem is the missing credentials for the external. However when I switch the 2.5.1 plugin to checkout version 1.6, it doesn't fail (kind of question that it should fail); but it also gives me the nice output message that points to the problem. Our actual setup is much more complicated and was a repo for a different group with an external in an external. So it was three deep and I didn't know it was there, but the credentials were stored in my .subversion cache so it checkout fine on my box.
Cleaning local Directory . Checking out svn://localhost/tmp/svn_test/repo1/project at revision '2015-08-20T10:17:40.280 -0500' AU test.txt U . At revision 2 WARNING: The following realms could not be authenticated: * <svn://localhost:3690> bc82e308-0615-4062-aeeb-e4222e8a1f7b Adding missing realms to configuration... Updated project configuration saved. Started calculate disk usage of build Finished Calculation of disk usage of build in 0 seconds Started calculate disk usage of workspace Finished Calculation of disk usage of workspace in 0 seconds Finished: SUCCESS
SVN Repo setup code for RedHat
#!/bin/bash #Created by Jeremy Eagan 08/20/2015 #Test case to setup svn repo for Jenkins Bug 27084 #Setup Instuctions # 1. Change the install location # 2. Beaware the script will turn on the svn server and kill it. # 3. Use at own risk, it should be safe but review for permissions and specific setup problems. # 4. Script will pause allowing you to run the Jenkins test, hit enter when Jenkins job is done to clean up the files. installLocation="/tmp" killsvn=false pushd . mkdir "${installLocation}/svn_test" cd "${installLocation}/svn_test" mkdir project echo "Testing" > project/test.txt #create some files to check in to repo svnadmin create repo1 svnadmin create repo2 #configure svn repos while read -r filename; do echo "[general]" > "$filename" echo "anon-access = none" >> "$filename" echo "auth-access = write" >> "$filename" echo "password-db = passwdnew" >> "$filename" done < <(find -name "svnserve.conf") #setup password files while read -r filename; do echo "[users]" > "$filename/passwdnew" userid=`echo $filename | sed 's/.*repo\([^/]*\).*/\1/'` echo "user${userid} = pa\$\$" >> "$filename/passwdnew" done < <(find -name conf) if [ "$(pgrep svnserve)" == "" ]; then echo "Starting SVN Server" svnserve -d #start svn server here if not started killsvn=true fi #add project to svn svn import project "file:///${installLocation}/svn_test/repo1/project" -m"Initial file add" svn import project "file:///${installLocation}/svn_test/repo2/project" -m"Initial file add" #checkout projects svn co "svn://localhost${installLocation}/svn_test/repo1/project" project1 --username user1 --password pa\$\$ --no-auth-cache #add externals and check in changes svn propset svn:externals "project2 svn://localhost${installLocation}/svn_test/repo2/project" project1 svn ci project1 -m"Adding project2 external to project1 repo" --username user1 --password pa\$\$ --no-auth-cache echo "Add svn://localhost${installLocation}/svn_test/repo1/project to your Jenkins Freestyle job with username=user1 password=pa\$\$" echo "SVN setup complete, ok to run jenkins test" read input rm "${installLocation}/svn_test" -rfv if ${killsvn}; then pgrep "svnserve" | xargs kill echo "SVN Server Shutdown" fi popd
Just to add some more info, the svn repo was run on the Jenkins slave running the job so the external pointing to localhost was valid.
Using plugin 2.5.1 with subversion 1.8 checkout and proper credentials
Cleaning local Directory . Checking out svn://localhost/tmp/svn_test/repo1/project at revision '2015-08-20T12:39:28.552 -0500' AU test.txt U . Fetching 'svn://localhost/tmp/svn_test/repo2/project' at -1 into '/local/jenkins/workspace/svn_test/project2' AU project2/test.txt At revision 1 At revision 2 no change for svn://localhost/tmp/svn_test/repo1/project since the previous build no change for svn://localhost/tmp/svn_test/repo2/project since the previous build Started calculate disk usage of build Finished Calculation of disk usage of build in 0 seconds Started calculate disk usage of workspace Finished Calculation of disk usage of workspace in 0 seconds Finished: SUCCESS
We had the same issue after a Jenkins update and could solve it by reentering the password on the credentials page.
The password is stored in the credentials.xml file in Jenkins home directory. When I reentered the (same) password, the encrypted password hash apparently changed in the credentials.xml.
Maybe the password encryption method of the credentials plugin changed recently and the hashes are not properly migrated?
I hope this can help for someone else...
reentering the password did not work for me on Jenkins ver. 1.609.2 with plugin version 2.5.3
zesty, Please review these comments because there are users with the problem solved.
If you prefer, you can file a new ticket in which provide a step by step to reproduce the bug.
I think there are multiple issues all presenting with the same error message. I didn't see an update to the code so I'm assuming nothing has been done to clear up the issues. I think for the problem I was having, issuing an error message in 2.5.1 similar to the error message in 1.6 would point the user to the resolution. This would at least separate out a common mistake that presents as one of the multiple issues under the "svn: E200015: authentication cancelled" error message.
mushadow, It would be great if you file a new ticket with a step by step process to reproduce the bug.
IMO, don't make sense to have this kind of tickets opened without any advance.
kamrup, thanks so much for your feedback. I'll close this ticket.
Hi ,
I am facing the same issue in jenkins 1.629 and subversion plugin 2.5.3 now.
I have read the above comments and found that upgrading the subversion from 2.5.1 to 2.5.3 fixed the issue.
can please you help me ?
I'm also having this issue, Jenkins 1.600, subversion 2.5.7. configuring -Dsvnkit.http.methods=Basic,NTLM,Negotiate,Digest did not help either... re-entering the credentials did not help either...
I resolved the issue with subversion plugin 2.6 and setting -Dsvnkit.http.methods=Basic parameter in jenkins.xml file. The first time i included it at the end but the parameter didn't get picked up. You should place it before -jar like ".... -Dsvnkit.http.methods=Basic -jar "%BASE%\jenkins.war".
I used just basic as I don't need anything else. You will see in System information if it gets picked up after restarting jenkins. Check Manage Settings/System Info and search for "svnkit.http.methods".
Jenkins ver. 2.7.1 / Subversion 2.6
Setting the svnkit.http.methods property to Basic in both the master and the slave did not make a difference for me.
The source code of svnkit authentication looks like a maze of protocols, managers and special cases. So I followed someone else's work-around by setting the Jenkins project's SCM to None and using the Cygwin's svn command in the first build step to check out the code. I had to add "--username USER --password PASSWORD" in a one-off invocation of the job to get svn store the credentials in the Jenkins agent's home.
set svn_opts=--non-interactive --trust-server-cert-failures unknown-ca,cn-mismatch,expired if exist .svn\nul ( %cygbinslash%svn.exe update %svn_opts% ) else ( %cygbinslash%svn.exe co %svn_opts% https://SERVER:PORT/svn/REPO/trunk/DIR . )
Hello all,
I have the same issue with Jenkins 1.609.3 and SVN 2.5.7
The error is intermittent, it works 50% of the time and when it fails, I get the "org.tmatesoft.svn.core.SVNCancelException: svn: E200015: authentication cancelled". If I retry, it will sometimes pass and complete the build.
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: authentication cancelled
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.io.svn.SVNSSHConnector.open(SVNSSHConnector.java:149)
at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.open(SVNConnection.java:77)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1273)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLatestRevision(SVNRepositoryImpl.java:172)
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:193)
I have a similar problem with the twist that util/lib is an http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html directory under the same subversion server.
The platform is Linux Ubuntu 16.04.
No changes for svn+ssh://svn.example.com/util since the previous build
hudson.util.IOException2: revision check failed on svn+ssh://svn.example.com/util/lib
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:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
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: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: authentication cancelled
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.io.svn.SVNSSHConnector.open(SVNSSHConnector.java:149)
at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.open(SVNConnection.java:77)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1273)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLatestRevision(SVNRepositoryImpl.java:172)
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
Archiving artifacts
Hi Jens,
Try adding "additional credentials" in your job with the realm defined as svn+ssh://svn.example.com with credentials that fit with that server/repo.
Thanks,
Channy
Thank you! That worked but I don't understand why it worked? Didn't I just specify the same credentials again without the specific directory?
Doesn't it try to use the same credentials when resolving an External?
And previous versions didn't have this problem.
See JENKINS-21785. It's supposedly a security enhancement on forcing externals to be explicitly defined with their credentials. Not sure why only the changelog calculation is affected and not the actual checkout... It definitely does not use the same credentials as the Repository URL anymore when accessing externals.
I'm getting the:
org.tmatesoft.svn.core.SVNCancelException: svn: E200015: authentication cancelled
When trying to connect to an Assembla SVN repository via SSH. I am able to connect via HTTP with a username and password but not through SSH. I've tried all of the workarounds listed here with no success.
Assembla requires that an environment variable called REPO_NAME be set and forwarded for svn+ssh. The environment variable is set and the SendEnv is configured in ~/.ssh/config:
Host subversion.assembla.com
SendEnv REPO_NAME
It works via the command line as the Jenkins user. Will this be send through the subversion plugin in Jenkins?
For what it's worth, I was getting "svn: E200015: authentication cancelled" because my svn repo was using a self signed cert. I had to add that cert to java's cacerts keystore, using portecle on Windows, and then it worked fine.
I'm seeing the same issue in a Linux environment, but our svn server uses NTLM.