[JIRA] [subversion] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials

488 views
Skip to first unread message

marcel@mcbeister.de (JIRA)

unread,
Feb 12, 2014, 7:18:39 AM2/12/14
to jenkinsc...@googlegroups.com
Change By: Marcel Beister (12/Feb/14 12:18 PM)
Description: We use svn:externals to map folders of the same repository into the project folders. The 2.1 version of the plugin fails to check for changes and reports a "svn: E200015: No credential to try. Authentication failed" error in the stack trace.

{noformat}
hudson.util.IOException2: revision check failed on https://svn.dummyserver.org/svn/Data/trunk/Dummy
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:189)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:736)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:651)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:560)
at hudson.model.Run.execute(Run.java:1670)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS / aisvn svn /Data/trunk/ MaterialDefinition Dummy  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.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: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.SVNLogClient.doLog(SVNLogClient.java:967)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:177)
... 11 more
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)
... 29 more
{noformat}
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

marcel@mcbeister.de (JIRA)

unread,
Feb 12, 2014, 7:18:39 AM2/12/14
to jenkinsc...@googlegroups.com
Issue Type: Bug Bug
Assignee: Unassigned
Components: subversion
Created: 12/Feb/14 12:17 PM
Description:

We use svn:externals to map folders of the same repository into the project folders. The 2.1 version of the plugin fails to check for changes and reports a "svn: E200015: No credential to try. Authentication failed" error in the stack trace.

hudson.util.IOException2: revision check failed on https://svn.dummyserver.org/svn/Data/trunk/Dummy
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:189)
	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:736)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:651)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:560)
	at hudson.model.Run.execute(Run.java:1670)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:231)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /aisvn/Data/trunk/MaterialDefinition 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.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: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.SVNLogClient.doLog(SVNLogClient.java:967)
	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:177)
	... 11 more
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)
	... 29 more
Environment: Windows 7 x64 for both hosts and slaves
Project: Jenkins
Priority: Major Major
Reporter: Marcel Beister

arnoutboks@gmail.com (JIRA)

unread,
Feb 13, 2014, 3:39:40 AM2/13/14
to jenkinsc...@googlegroups.com
Arnout Boks commented on Bug JENKINS-21785

I also encounter this issue, on a Debian machine in my case.

The strange thing is that if, after such a "No credential to try" failure, the next (manually started) build always seems to run fine.

I have not listed all externals as separate 'modules' in my job configuration, but I have configured additional credentials for the realm to which all externals belong.

marcel@mcbeister.de (JIRA)

unread,
Feb 13, 2014, 3:43:38 AM2/13/14
to jenkinsc...@googlegroups.com

It seems that the error only occurs on some of the svn:externals, but I can't find a pattern. A manual next build did not solve the issue for me.

dvannieuwenborgh@ompartners.com (JIRA)

unread,
Feb 14, 2014, 2:08:38 PM2/14/14
to jenkinsc...@googlegroups.com

I notice the same in our setup. After an upgrade, none of our jobs work correctly as we get "Authentication failures" randomly on one or more externals.
When reverting to 1.54, everything works fine again.
Very annoying that after a simple upgrade your complete installation does not work anymore ...

josesa@java.net (JIRA)

unread,
Feb 18, 2014, 12:42:38 PM2/18/14
to jenkinsc...@googlegroups.com
Jose Sa commented on Bug JENKINS-21785

I see similar issue with some externals (not all) with following exception:

Feb 18, 2014 7:19:48 PM hudson.scm.SubversionRepositoryStatus$JobTriggerListenerImpl onNotify
WARNING: Failed to handle Subversion commit notification
org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svnroot/repo/path/to/external 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.getRepositoryUUID(DAVRepository.java:148)
        at hudson.scm.SubversionSCM$ModuleLocation.getUUID(SubversionSCM.java:2700)
        at hudson.scm.SubversionRepositoryStatus$JobTriggerListenerImpl.onNotify(SubversionRepositoryStatus.java:202)
        at hudson.scm.SubversionRepositoryStatus.doNotifyCommit(SubversionRepositoryStatus.java:136)
        at sun.reflect.GeneratedMethodAccessor348.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298)
        at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161)
        at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96)
        at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:120)
        at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
        at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
        at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
        at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:390)
        at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
        at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
        at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:390)
        at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
        at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
        at org.kohsuke.stapler.Stapler.invoke(Stapler.java:631)
        at org.kohsuke.stapler.Stapler.service(Stapler.java:225)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
        at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)
        at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)
        at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:96)
        at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:203)
        at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181)
        at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)
        at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:90)
        at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
        at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58)
        at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
        at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:88)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
        at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:174)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:79)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
        at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
        at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:46)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at winstone.RequestDispatcher.forward(RequestDispatcher.java:331)
        at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:227)
        at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
        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 winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:679)
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 hudson.scm.FilterSVNAuthenticationManager.getFirstAuthentication(FilterSVNAuthenticationManager.java:35)
        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)
        ... 84 more
Feb 18, 2014 7:19:48 PM hudson.scm.SubversionRepositoryStatus$JobTriggerListenerImpl onNotify
WARNING: No subversion jobs using repository: 9ab88d41-efc2-4aad-9281-006de71726b0

I've reviewed credentials and even forced the same credentialsId in all subversion jobs using groovy script but still the stack traces show up. It seems as if from error message the protocol+server+port is missing as it doesn't look like an url, could the exception print also the job or referent url that refers to that "external" to help debug ?

thorsten.stahl@tstahl.de (JIRA)

unread,
Feb 25, 2014, 4:38:59 AM2/25/14
to jenkinsc...@googlegroups.com

I've got the same error since we updated the Subversion-Plugin from 1.54 to 2.2.
I found a pattern in my case. This only happens with our repository trigger and only with jobs, which have a special svn:externals definition.
The svn:externals are defined absolute (not relative) and refer another repository on the same host. 'Add additional credentials' don't work in all experiments with any kind of name-permutation in the 'Realm' field.
Other jobs with svn:externals relative to their own repository works fine, even if i start the problem jobs manually.
As work around i add the regarding external-url to the 'Source Code Management' section in the job configuration page and set the the repository depth to 'empty' and the 'Local module directory' to 'dummy_xxx'.

josesa@java.net (JIRA)

unread,
Feb 25, 2014, 4:54:58 AM2/25/14
to jenkinsc...@googlegroups.com
Jose Sa commented on Bug JENKINS-21785

I had enable the polling from master option on startup "-Dhudson.scm.SubversionSCM.pollFromMaster=true" and after disabling it and restarting server, rechecking the polling from the slave instead of master now all urls fail to check with same stack trace.

svn checkout doesn't seem to have a problem.

Tested with Jenkins LTS 1.532.2 and svn plugin 2.2

josesa@java.net (JIRA)

unread,
Feb 26, 2014, 3:36:58 AM2/26/14
to jenkinsc...@googlegroups.com
Jose Sa commented on Bug JENKINS-21785

After some additional testing it seems that subversion plugin is relying on host svn client configuration looking into $HOME/.subversion for the credentials instead of of using the ones configured in Jenkins.

When I used a Windows slave that didn't had a svn client installed or removed .subversion on linux slaves or master the problem to check on all urls is shown in scm polling log.

hinrich@prostep.com (JIRA)

unread,
Feb 26, 2014, 9:14:58 AM2/26/14
to jenkinsc...@googlegroups.com
WH commented on Bug JENKINS-21785

Similar problem here (Jenkins LTS 1.532.2 and Subversion Plugin 2.2):
Project1 has svn:externals property "^/project2/trunk/directory directory".

Checking out svn+ssh://server/repo/project1/trunk@3895 at revision 3895
A         xxx.xxx
...
 U        .
Fetching 'svn+ssh://server/repo/project2/trunk/directory' at -1 into 'C:\slavedir\workspace\jobdir\f99eb302\directory'
A         directory\yyy.yyy
...
 U        directory
At revision 3895
At revision 3895
hudson.util.IOException2: revision check failed on svn+ssh://server/repo/project2/trunk/directory
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:189)
	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:738)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:899)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561)
	at hudson.model.Run.execute(Run.java:1665)
	at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:246)
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.svn.SVNSSHConnector.open(SVNSSHConnector.java:77)
	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:1252)
	at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLatestRevision(SVNRepositoryImpl.java:168)
	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.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: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.SVNLogClient.doLog(SVNLogClient.java:967)
	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:177)
	... 11 more
This message is automatically generated by JIRA.

hinrich@prostep.com (JIRA)

unread,
Feb 26, 2014, 9:20:59 AM2/26/14
to jenkinsc...@googlegroups.com
WH updated Bug JENKINS-21785
Change By: WH (26/Feb/14 2:19 PM)
Priority: Major Blocker

chikigai@java.net (JIRA)

unread,
Mar 3, 2014, 12:12:58 AM3/3/14
to jenkinsc...@googlegroups.com
chikigai commented on Bug JENKINS-21785

Same issue here with Jenkins 1.552 and Subversion Plugin 2.2 using Windows7 slaves.
All of our jobs configured to access SVN repositories via the svn:externals property are failing due to authentication failures.
Externals set to paths within the same repository and with different repositories both fail.
Setting "Additional Credentials" makes no difference whatsoever.

andrei@k-tz.com (JIRA)

unread,
Mar 4, 2014, 6:13:16 PM3/4/14
to jenkinsc...@googlegroups.com

Same problem, Jenkins 1.552, SVN plugin 2.2, on RH Linux and Windows 7/2003.

Checkout works fine, but polling and change log querying randomly fail. There is no difference whether a build was started manually or triggered.

All svn:externals reference the same repo (^). The failures happen at random places; one external is queried successfully now and then fails on the next run.

chikigai@java.net (JIRA)

unread,
Mar 4, 2014, 9:50:17 PM3/4/14
to jenkinsc...@googlegroups.com
chikigai commented on Bug JENKINS-21785

Some additional information.
There's definitely some randomness in the authentication failures, but I've spotted a case where it occurs very frequently - svn:externals set to point to a file in the same repository.

soukupmi@gmail.com (JIRA)

unread,
Mar 7, 2014, 5:25:18 AM3/7/14
to jenkinsc...@googlegroups.com

same problem
found this bug-entry too late, so I opened another: JENKINS-22078

soukupmi@gmail.com (JIRA)

unread,
Mar 7, 2014, 5:39:16 AM3/7/14
to jenkinsc...@googlegroups.com

seems additional credentials for this specific external (same credentials as for the root project with the realm being the url to the external repo) made it work, but I have no intention of doing this for all my 50 projects...

soukupmi@gmail.com (JIRA)

unread,
Mar 7, 2014, 8:55:16 AM3/7/14
to jenkinsc...@googlegroups.com
 
michael soukup edited a comment on Bug JENKINS-21785

seems additional credentials for this specific external (same credentials as for the root project with the realm being the url to the external repo) made it work, but I have no intention of doing this for all my 50 projects...
edit: This did not work at all, the test case i made for it did that (see workaround)

workaround that works for me at the moment:

  • create new project that watches the changes in my library (the external that is in common for all and fails with the revision check, repository depth=empty)
  • configure other project as triggered by this new one

this seems to make the revision check work properly

josesa@java.net (JIRA)

unread,
Mar 7, 2014, 10:33:16 AM3/7/14
to jenkinsc...@googlegroups.com
Jose Sa commented on Bug JENKINS-21785

what I'm currently doing is setup a subversion specific domain with all svn hosts listed (using wildcards and independent of protocol) with a using a single credential account to access all svn repositories.

Then I get that credential ID from browser url which is something like "6c9118bf-622a-498d-b244-3c3382d73a39"

To apply that credential to all jobs matching a regular expression I use the following groovy script:

/*** BEGIN META {
  "name" : "scm_svn_credentials",
  "comment" : "Check/Fix subversion credentials in jobs",
  "parameters" : [ 'CREDENTIALS', 'JOBS_PAT' ],
  "core": "1.532.2",
  "authors" : [
    { name : "Jose Miguel Sa" }
  ]
} END META**/

import hudson.scm.*

/** set input values **/
//String CREDENTIALS = "6c9118bf-622a-498d-b244-3c3382d73a39";
//String JOBS_PAT = ".*";

/** bulk apply changes **/
def updateSvn(job, CREDENTIALS) {
    def locations = [];
    for (loc in job.scm.getLocations()) {
        if ( CREDENTIALS != "" ) loc = loc.withCredentialsId(CREDENTIALS);
        locations.add(loc);
    }
    job.setScm(new SubversionSCM(locations,
        job.scm.workspaceUpdater,
        job.scm.browser,
        job.scm.excludedRegions,
        job.scm.excludedUsers,
        job.scm.excludedRevprop,
        job.scm.excludedCommitMessages,
        job.scm.includedRegions,
        job.scm.ignoreDirPropChanges,
        job.scm.filterChangelog,
        job.scm.additionalCredentials));
}

def printSvnLoc(loc) {
    println "  Location: $loc.remote";
    println "    local: $loc.local";
    println "    credentialsId: $loc.credentialsId";
    println "    depthOption: $loc.depthOption";
    println "    ignoreExternalsOption: $loc.ignoreExternalsOption";
}

def instance = hudson.model.Hudson.getInstance();
def jobs = instance.items;
for (job in jobs.findAll{ it.name =~ /^${JOBS_PAT}$/ }) {
    if (job instanceof hudson.model.ExternalJob) continue;
    if (job.scm instanceof hudson.scm.SubversionSCM) {
        println "\n[ job: $job.name ]";

       // Comment the following line when ready to efectivelly apply changes
    /*
        updateSvn(job, CREDENTIALS);
    //*/

        // check current values
        for (loc in job.scm.getLocations()) {
            printSvnLoc(loc);
        }
        println "  workspaceUpdater: $job.scm.workspaceUpdater";
        println "  browser: $job.scm.browser";
        println "  excludedRegions: $job.scm.excludedRegions";
        println "  excludedUsers: $job.scm.excludedUsers";
        println "  excludedRevprop: $job.scm.excludedRevprop";
        println "  excludedCommitMessages: $job.scm.excludedCommitMessages";
        println "  includedRegions: $job.scm.includedRegions";
        println "  ignoreDirPropChanges: $job.scm.ignoreDirPropChanges";
        println "  filterChangelog: $job.scm.filterChangelog";
        println "  additionalCredentials: $job.scm.additionalCredentials";
    }
}

Which aplies correctly the same credential to all svn locations, but still the actual changelog checks are failing because instead of relying on svnkit implementation it is delegating those to svn client installed in the account running the scm polling process, in Jenkins if polling from master is set, or from slaves otherwise.

daniel@beckweb.net (JIRA)

unread,
Mar 8, 2014, 6:53:17 AM3/8/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

I think I fixed the case of exceptions during post-commit notifications (notifyCommit):

https://github.com/daniel-beck/subversion-plugin/tree/notify-commit-external-credentials
https://github.com/daniel-beck/subversion-plugin/commit/aabd40a550461b08296ff3e971c80915ba22d9e0

Have never seen the specific exception stack trace from the original report, so I don't know whether that is also resolved (but I doubt it).

I resolved exceptions during polling by specifying additional credentials.

daniel@beckweb.net (JIRA)

unread,
Mar 8, 2014, 6:58:17 AM3/8/14
to jenkinsc...@googlegroups.com
 
Daniel Beck edited a comment on Bug JENKINS-21785

I think I fixed the case of exceptions during post-commit notifications (notifyCommit):

https://github.com/daniel-beck/subversion-plugin/tree/notify-commit-external-credentials
https://github.com/daniel-beck/subversion-plugin/commit/aabd40a550461b08296ff3e971c80915ba22d9e0
(not a PR because it's not nice enough; feel free to build on this)

Have never seen the specific exception stack trace from the original report, so I don't know whether that is also resolved (but I doubt it).

To be specific, this is the case I resolved with this change:

1. Set up an SVN repo, anywhere. Can be locally file://...; no auth required.
2. Add an external somewhere that required credentials for access (below I used a repo accessed via HTTPS)
3. Check out the first repo
4. Build once to get the 'WARNING: The following realms could not be authenticated'
5. Configure additional credential for the realm it complains about, build again
6. No warning this time, external gets checked out
7. Script console:

def p = Jenkins.instance.getItemByFullName('p=jobname')
p.scm.getProjectLocations(p).findAll { it.remote.startsWith('https://') }.each { println it.getUUID(p) }

Result

org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/... 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.getRepositoryUUID(DAVRepository.java:148)
at hudson.scm.SubversionSCM$ModuleLocation.getUUID(SubversionSCM.java:2707)
at (user script)
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 hudson.scm.FilterSVNAuthenticationManager.getFirstAuthentication(FilterSVNAuthenticationManager.java:35)
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)
... 89 more

daniel@beckweb.net (JIRA)

unread,
Mar 8, 2014, 6:58:17 AM3/8/14
to jenkinsc...@googlegroups.com
 
Daniel Beck edited a comment on Bug JENKINS-21785

I think I fixed the case of exceptions during post-commit notifications (notifyCommit):

https://github.com/daniel-beck/subversion-plugin/tree/notify-commit-external-credentials
https://github.com/daniel-beck/subversion-plugin/commit/aabd40a550461b08296ff3e971c80915ba22d9e0
(not a PR because it's not nice enough; feel free to build on this)

Have never seen the specific exception stack trace from the original report, so I don't know whether that is also resolved (but I doubt it).

To be specific, this is the case I resolved with this change:

1. Set up an SVN repo, anywhere. Can be locally file://...; no auth required.
2. Add an external somewhere that required credentials for access (below I used a repo accessed via HTTPS)
3. Check out the first repo
4. Build once to get the 'WARNING: The following realms could not be authenticated'
5. Configure additional credential for the realm it complains about, build again
6. No warning this time, external gets checked out
7. Script console:

def p = Jenkins.instance.getItemByFullName('jobname')
p.scm.getProjectLocations(p).findAll { it.remote.startsWith('https://') }.each { println it.getUUID(p) }

Result

org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/... 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.getRepositoryUUID(DAVRepository.java:148)
at hudson.scm.SubversionSCM$ModuleLocation.getUUID(SubversionSCM.java:2707)
at (user script)
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 hudson.scm.FilterSVNAuthenticationManager.getFirstAuthentication(FilterSVNAuthenticationManager.java:35)
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)
... 89 more

joce@codizy.Com (JIRA)

unread,
Mar 8, 2014, 3:25:17 PM3/8/14
to jenkinsc...@googlegroups.com

Same issue here, svn:externals on a local directory inside the same project, and it fails randomly.

hudson.util.IOException2: revision check failed on http://****/client/application/class
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:189)
	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:738)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:899)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
	at hudson.model.Run.execute(Run.java:1676)
	at hudson.matrix.MatrixBuild.run(MatrixBuild.java:304)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:231)
	at hudson.model.OneOffExecutor.run(OneOffExecutor.java:43)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /*****/client/application/class 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.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: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.SVNLogClient.doLog(SVNLogClient.java:967)
	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:177)
	... 12 more
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)
	... 30 more
Finished: FAILURE

joce@codizy.Com (JIRA)

unread,
Mar 8, 2014, 3:27:16 PM3/8/14
to jenkinsc...@googlegroups.com
 
jocelyn fournier edited a comment on Bug JENKINS-21785

Same issue here on linux debian, svn:externals on a local directory inside the same project (../../client/application/class class) , and it fails randomly.

hudson.util.IOException2: revision check failed on http://****/client/application/class
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:189)
	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:738)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:899)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
	at hudson.model.Run.execute(Run.java:1676)
	at hudson.matrix.MatrixBuild.run(MatrixBuild.java:304)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:231)
	at hudson.model.OneOffExecutor.run(OneOffExecutor.java:43)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /*****/client/application/class 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.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: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.SVNLogClient.doLog(SVNLogClient.java:967)
	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:177)
	... 12 more
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)
	... 30 more
Finished: FAILURE

daniel@beckweb.net (JIRA)

unread,
Mar 8, 2014, 3:48:17 PM3/8/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

Jocelyn: That particular issue looks like you can resolve it by adding an "additional credentials" entry below the list of module locations with a valid credential.

For realm, enter e.g.

<https://server:443> Subversion Authentication

It's the protocol, host, and port of the SVN service. The realm name (Subversion Authentication in my example is what your web browser shows in the password dialog when trying to access that URL.

joce@codizy.Com (JIRA)

unread,
Mar 8, 2014, 7:07:17 PM3/8/14
to jenkinsc...@googlegroups.com

Thanks Daniel, so far it seems it works perfectly

pavel.punsky@oovoo.com (JIRA)

unread,
Mar 9, 2014, 10:33:16 AM3/9/14
to jenkinsc...@googlegroups.com

Same here - after upgrade to plugin 2.2

daniel@beckweb.net (JIRA)

unread,
Mar 9, 2014, 10:51:17 AM3/9/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

Does anyone experiencing the problem "No credential to try. Authentication failed" not fall in either of the following categories:

If so, please add a comment and be really specific about the circumstances the problem appears in, as well as what happens (full stack trace, Jenkins log, ...).

soukupmi@gmail.com (JIRA)

unread,
Mar 10, 2014, 5:52:16 AM3/10/14
to jenkinsc...@googlegroups.com

adding this to all the job config.xml files

<additionalCredentials>
   <hudson.scm.SubversionSCM_-AdditionalCredentials>
     <realm>&lt;https://[ServerName]:8443&gt; VisualSVN Server</realm>
     <credentialsId>....</credentialsId>
   </hudson.scm.SubversionSCM_-AdditionalCredentials>
</additionalCredentials>

and restarting the server worked for me
thank you, Daniel

note: this equals entering

<https://[ServerName]:8443> VisualSVN Server
in each job configuration, but was much easier to do

soukupmi@gmail.com (JIRA)

unread,
Mar 10, 2014, 5:54:16 AM3/10/14
to jenkinsc...@googlegroups.com
 
michael soukup edited a comment on Bug JENKINS-21785

adding this to all the job config.xml files (copied from one job where I entered the realm and credentials through the config tab)

<additionalCredentials>
   <hudson.scm.SubversionSCM_-AdditionalCredentials>
     <realm>&lt;https://[ServerName]:8443&gt; VisualSVN Server</realm>
     <credentialsId>....</credentialsId>
   </hudson.scm.SubversionSCM_-AdditionalCredentials>
</additionalCredentials>

and restarting the server worked for me
thank you, Daniel

note: this equals entering

<https://[ServerName]:8443> VisualSVN Server

in each job configuration as realm, but was much easier to do

chikigai@java.net (JIRA)

unread,
Mar 10, 2014, 10:53:16 PM3/10/14
to jenkinsc...@googlegroups.com
chikigai commented on Bug JENKINS-21785

Daniel: I am still experiencing authentication failures even with the additional credentials set.
My setup has Jenkins 1.552 and Subversion Plugin 2.2 (All Windows7 master/slaves).
There are several jobs checking out repositories with SVN externals set. All fail randomly.
One of the simpler jobs checks out a working directory from a repository with the following structure:

RepoA
├── ProjectA
│      └── trunk
│            ├── FolderA
│            └── FolderB
└── ProjectB
       └── trunk
              ├── FolderA
              └── FolderB <--- SVN External (^/ProjectA/trunk/FolderB)

ProjectB/trunk is set to be checked out, and the authentication fails on the SVN external.
I have added "Additional Credentials" with the realm set for RepoA, but still get "No credential to try. Authentication failed" as in the following stack trace:

hudson.util.IOException2: revision check failed on http://xxxxx/svn/ProjectA/trunk/FolderB
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:189)
	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:738)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:899)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561)
	at hudson.model.Run.execute(Run.java:1665)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:246)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/xxxxx/svn/ProjectA/trunk/FolderB 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.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: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.SVNLogClient.doLog(SVNLogClient.java:967)
	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:177)
	... 11 more
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)
	... 29 more

soukupmi@gmail.com (JIRA)

unread,
Mar 11, 2014, 9:04:16 AM3/11/14
to jenkinsc...@googlegroups.com
Change By: michael soukup (11/Mar/14 1:03 PM)
Attachment: Jenkins-credentials.png

soukupmi@gmail.com (JIRA)

unread,
Mar 11, 2014, 9:24:17 AM3/11/14
to jenkinsc...@googlegroups.com

@chikigai:
the mistake I at first made was to enter the complete url to the external subproject as realm.
you have to enter it like in the screenshot I attached:

make sure to include the pointy brackets and to enter the title the server responses when you access it through the web interface (as Daniel said in comment-196363)
Our server provides this dialog
so "VisualSVN Server" is what I entered after the host-url (which is the one under the white rectangle).

This works for us and as we have a repository structure very similar to yours hopefully also works for you.

ivan@kumobius.com (JIRA)

unread,
Mar 11, 2014, 5:41:16 PM3/11/14
to jenkinsc...@googlegroups.com
Ivan Neeson commented on Bug JENKINS-21785

Does anybody know how to find out what realm to enter if you're using the "svn://" protocol, not http?

daniel@beckweb.net (JIRA)

unread,
Mar 11, 2014, 7:12:16 PM3/11/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

Alternative ways to find out your auth realm:

Command line SVN:

svn --no-auth-cache --config-dir invalid info proto://host:port/path/to/repo will show the auth realm, possibly after asking you to accept the certificate temporarily.

$ svn --no-auth-cache --config-dir invalid info proto://host:port/path/to/repo
Authentication realm: <proto://host:port> VisualSVN Server
Password for 'danielbeck':

(invalid is the name of the directory – --config-dir – to get SVN client config from; in this case, should be non-existing dir, resulting in ignoring existing preferences like saved credentials). The dir will likely be created, just delete it afterwards.

Check the server config

If you use svnserve to serve the repo, check the realm directive in the [general] section of /path/to/repo/conf/svnserve.conf.

Patch the Subversion plugin

Unfortunately, logging is lacking in the current version of the plugin. This patch adds logging of URL and realm to auth attempts (logger hudson.scm.CredentialsSVNAuthenticationProviderImpl, level FINE):
https://github.com/daniel-beck/subversion-plugin/commit/e210707cef0dd419af4c0e4f409f0a16ef942156

Ask your SVN admin

Seriously. They'll know. (If you're the admin, well, maybe you shouldn't be.)

chikigai@java.net (JIRA)

unread,
Mar 11, 2014, 7:43:16 PM3/11/14
to jenkinsc...@googlegroups.com
chikigai commented on Bug JENKINS-21785

@michael soukup
Thank you for the detailed description.
However, I have already entered the realm as you have explained.
As I have stated in my previous comments, the failures are very random.
The authentication succeeds on some occasions, and fails on others.
I've even had the authentication succeed on the external without any additional credentials on some occasions.
Therefore, I am quite doubtful that the failures I am facing have anything to do with additional credentials.

daniel@beckweb.net (JIRA)

unread,
Mar 11, 2014, 7:57:17 PM3/11/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

Chikigai: It's likely a specific set of circumstances you didn't determine yet.

  • Does it affect only certain projects?
  • Does it affect only builds executing on certain slaves?
  • Does it affect only certain actions (checkout, SVN post-commit hook, polling, ...)
  • Does it affect only builds using a clean (or pre-existing) workspace?
  • Does it affect only projects without existing builds?
  • ...

if there's any variation in stack traces with the exception, posting those would be useful as well.

For example, I didn't even notice this problem (affected were polling and post-commit hook; resolved by adding extra credentials and patching the plugin, respectively) at first, as manually started builds successfully checked out everything, including the external. It's just that no build was able to detect changes in the external location (+ tons of exceptions logged like this one).

chikigai@java.net (JIRA)

unread,
Mar 12, 2014, 1:15:18 AM3/12/14
to jenkinsc...@googlegroups.com
chikigai commented on Bug JENKINS-21785

@Daniel Beck
OK, here's some more info which hopefully would be of some use.
Let me explain with some additions to the repository structure I used previously:

RepoA
├── ProjectA
│      └── trunk
│            ├── FolderA
│            └── FolderB
│                    └── external.c
└── ProjectB
       └── trunk
              ├── FolderA
              │     └── internal.c
              └── FolderB <--- SVN External (^/ProjectA/trunk/FolderB)

I have two jobs where:
[Job A]
Checks out ProjectA/trunk and then triggers Job B. (I created this job since changes in "external.c" would not be picked and trigger Job B)

[Job B]
Checks out ProjectB/trunk and runs a build.
Contains an additional credential as discussed in earlier comments.

And now a list of build triggers I tried with results:
[Job A + Manual trigger]
Job A succeeds, Job B is triggered and succeeds.

[Job B + Manual trigger]
Job B succeeds.

[Change/Commit "internal.c" + post-commit hook trigger]
Job B succeeds.

[Change/Commit "external.c" + post-commit hook trigger]
Job A succeeds, Job B is triggered and fails with authentication failure on the SVN external.
This failure occurs every single time via a post-commit hook trigger when "external.c" is commited.
Stack trace is exactly the same as posted in comment-196434.

alex.d.alexeev@gmail.com (JIRA)

unread,
Mar 12, 2014, 10:33:17 AM3/12/14
to jenkinsc...@googlegroups.com

I've same problem after update to 1.554

And I have workaround for this bug.
I changed svn update option to
"Emulate clean checkout by first deleting unversioned/ignored files, then 'svn update'"

soukupmi@gmail.com (JIRA)

unread,
Mar 13, 2014, 4:45:16 AM3/13/14
to jenkinsc...@googlegroups.com

@Alexander: I tried that ("Emulate clean checkout by first deleting unversioned/ignored files, then 'svn update'") today after updating to 1.554 - did not work.
same response as usual:

Started on 13.03.2014 08:41:58
Received SCM poll call ...
ERROR: Failed to check repository revision for https://[server]:8443/svn/IAB2.5/trunk/Library
org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/IAB2.5/trunk/Library failed
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384)
	...
	at java.lang.Thread.run(Unknown Source)
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)

with the additional realm:

Started on 13.03.2014 09:26:04
Received SCM poll call on  for GATS on 13.03.2014 09:26:04
https://[server]:8443/svn/IAB2.5/branches/...GATS is at revision 6.235
https://[server]:8443/svn/IAB2.5/trunk/Library is at revision 7.106
https://[server]:8443/svn/IAB2.5/Projekte/...GATS is at revision 6.935
Done. Took 0,49 sec
No changes

soukupmi@gmail.com (JIRA)

unread,
Mar 13, 2014, 4:53:16 AM3/13/14
to jenkinsc...@googlegroups.com

@chikigai: you said

I have two jobs where:
[Job A]
Checks out ProjectA/trunk and then triggers Job B. (I created this job since changes in "external.c" would not be picked and trigger Job B)

[Job B]
Checks out ProjectB/trunk and runs a build.
Contains an additional credential as discussed in earlier comments.

did you also try with entering the additional credentials for Job A, too?

chikigai@java.net (JIRA)

unread,
Mar 13, 2014, 5:50:16 AM3/13/14
to jenkinsc...@googlegroups.com
chikigai commented on Bug JENKINS-21785

@michael soukup
Yes, I tried with additional credentials for Job A and Job B still fails.
If it worked however, I would be wondering how the credentials for one job would affect another.

daniel@beckweb.net (JIRA)

unread,
Mar 13, 2014, 5:54:16 AM3/13/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

@~chikigai: Is the behavior independent of whether a workspace already exists, and independent of whether earlier builds exist? Please create new projects just with the SCM config if necessary. I'll try to take a look at this tomorrow or on the weekend if I know how to reliably reproduce the problem.

chikigai@java.net (JIRA)

unread,
Mar 13, 2014, 6:37:16 AM3/13/14
to jenkinsc...@googlegroups.com
chikigai commented on Bug JENKINS-21785

@Daniel Beck
I created a repository exactly as posted in comment-196534.
Also created fresh jobs for Job A & B which only perform a checkout. (Additional credentials added too)
Here's what happened:

[Change/Commit "external.c" + post-commit hook trigger]

First time: Job A succeeds, Job B is triggered and succeeds.
Second time and onwards: Job A succeeds, Job B is triggered and fails.

I then deleted the workspace for Job B and tried again.
Job B fails.

I then deleted previous build related data and the workspace for job B and tried again.
No problems first time and Job B fails from second time onwards.

I then deleted previous build related data tried again.
No problems first time and Job B fails from second time onwards.

So with the fresh jobs and repository I used, it looks like previous build data of Job B is the failing factor.

chikigai@java.net (JIRA)

unread,
Mar 13, 2014, 6:39:18 AM3/13/14
to jenkinsc...@googlegroups.com
 
chikigai edited a comment on Bug JENKINS-21785

@Daniel Beck
I created a repository exactly as posted in comment-196534.
Also created fresh jobs for Job A & B which only perform a checkout. (Additional credentials added too)
Here's what happened:

[Change/Commit "external.c" + post-commit hook trigger]
First time: Job A succeeds, Job B is triggered and succeeds.
Second time and onwards: Job A succeeds, Job B is triggered and fails.

I then deleted the workspace for Job B and tried again.
Job B fails.

I then deleted previous build related data and the workspace for job B and tried again.
No problems first time and Job B fails from second time onwards.

I then deleted previous build related data for job B and tried again. (left the workspace untouched)


No problems first time and Job B fails from second time onwards.

So with the fresh jobs and repository I used, it looks like previous build data of Job B is the failing factor.

soukupmi@gmail.com (JIRA)

unread,
Mar 13, 2014, 9:25:17 AM3/13/14
to jenkinsc...@googlegroups.com

Our repository structure in the SVN looks like this:

IAB2.5
  +-- trunk
  |     +-- Library
  |           +-- FolderA
  |           |     +-- externalA.c
  |           +-- FolderB
  |           |     +-- externalB.c
  |           +-- externalC.c
  |
  +-- branches
  |     +-- ProjectA
  |     |     +-- FolderA
  |     |     |     +-- external1.c
  |    	|     +-- FolderB
  |    	|     |     +-- external2.c
  |    ...    +-- external3.c
  |
  +-- Projects
        +-- ProjectB       <--- Jenkins Job A - watched for svn changes
        |     +-- FolderA  <--- SVN External (^/trunk/Library)
        |     +-- FolderB  <--- SVN External (^/branches/ProjectA)
        |     +-- FolderC
        |           +-- internal.c
        |
        +-- ProjectB1      <--- Jenkins Job B - triggered by Job A
        |     +-- FolderA  <--- SVN External (^/trunk/Library)
        |     +-- FolderB  <--- SVN External (^/branches/ProjectA1)
        |     +-- FolderC
       ...          +-- internal.c

Job A in Jenkins triggers on all SVN changes in the root Project, e.g.

  • externalA.c
  • externalB.c
  • external2.c
  • external3.c
  • internal.c

--> they all trigger the checkout and rebuild of our ProjectB.
So a change in your external.c should be able to trigger your Job B too, as there is a new revision number created for it on the commit.

Also our ProjectB1 gets built by Job B which is started by Job A after it has finished.
They all work well now (all Jobs with additional credentials set, though).

Anyway, instead of post-commit hook trigger or any other hook we use svn polling (check repository every 1/4 hour). Could this be the reason why our setup works?

daniel@beckweb.net (JIRA)

unread,
Mar 13, 2014, 3:52:17 PM3/13/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

Chikigai: I may have fixed your issue. Completely untested (don't have a suitable test environment right now):
Commit: https://github.com/daniel-beck/subversion-plugin/commit/bb33856de17663faf1a26eebe86ba00076053394
Branch: https://github.com/daniel-beck/subversion-plugin/tree/notify-commit-external-credentials

How to checkout and build:

git clone https://github.com/daniel-beck/subversion-plugin.git . ; git checkout notify-commit-external-credentials ; mvn -DskipTests=true

chikigai@java.net (JIRA)

unread,
Mar 13, 2014, 9:58:19 PM3/13/14
to jenkinsc...@googlegroups.com
chikigai commented on Bug JENKINS-21785

@Daniel Beck
Forgive me for my lack of knowledge (this is the first time I'm build a Jenkins Plugin), but I'm unable to test your fix.
Here's what I tried:

1. Clone subversion-plugin
2. Checkout notify-commit-external-credentials
3. Build using maven
4. Installed subversion.hpi created in the target directory

The plugin is based on version 1.45 (shown in the installed plugins page) and does not recognize the credential related job settings.
I will have to add the credential again using the older method, but surely this is not what's expected.
I'm assuming I got something wrong here, so can you possibly point me in the right direction?

chikigai@java.net (JIRA)

unread,
Mar 13, 2014, 10:15:16 PM3/13/14
to jenkinsc...@googlegroups.com


So a change in your external.c should be able to trigger your Job B too, as there is a new revision number created for it on the commit.

Yes, that's what I expect too.
However, I have had some cases where the build would not start.
(Bare in mind the repository structure and externals set are far more complex than the example I've used)
I'm planning to look into this again once this issue with credentials is sorted out.

chikigai@java.net (JIRA)

unread,
Mar 13, 2014, 10:17:17 PM3/13/14
to jenkinsc...@googlegroups.com
 
chikigai edited a comment on Bug JENKINS-21785

@Daniel Beck
Forgive me for my lack of knowledge (this is the first time I'm building a Jenkins Plugin), but I'm unable to test your fix.


Here's what I tried:

1. Clone subversion-plugin
2. Checkout notify-commit-external-credentials
3. Build using maven
4. Installed subversion.hpi created in the target directory

The plugin is based on version 1.45 (shown in the installed plugins page) and does not recognize the credential related job settings.
I will have to add the credential again using the older method, but surely this is not what's expected.
I'm assuming I got something wrong here, so can you possibly point me in the right direction?
This message is automatically generated by JIRA.

daniel@beckweb.net (JIRA)

unread,
Mar 13, 2014, 10:19:17 PM3/13/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

Chikigai: Subversion plugin 1.45 is bundled with Jenkins from 1.514-1.553, so it looks like you're back to the version bundled with your Jenkins.

If you installed the plugin by first removing everything in the $JENKINS_HOME/plugins folder whose name starts with subversion, start over, but this time create (or keep) the empty file named subversion.jpi.pinned – it prevents override from bundled plugins. The safest way to install/update is by using the file upload in Manage Jenkins » Manage Plugins » Advanced (if you're on 1.512 or later).

If my assumption is wrong, explain in detail how you installed the plugin.

daniel@beckweb.net (JIRA)

unread,
Mar 13, 2014, 10:21:16 PM3/13/14
to jenkinsc...@googlegroups.com
 
Daniel Beck edited a comment on Bug JENKINS-21785

chikigai@java.net (JIRA)

unread,
Mar 14, 2014, 1:23:16 AM3/14/14
to jenkinsc...@googlegroups.com
chikigai commented on Bug JENKINS-21785

@Daniel Beck
Thank you very much for the pointer.
I was manually removing the plugin from the plugins folder including the pin.
This time, I left the pin following your instructions and the plugin installed fine.
(Can't use the plugin upload feature since I always get a "Failed to dynamically deploy this plugin" error)

Unfortunately, I got the exact same authentication failure from the second time onwards:
1. Deleted previous build related data for job B. (left the workspace untouched)
2. Change/Commit "external.c" + post-commit hook trigger
3. Jobs A & B both succeed
4. Change/Commit "external.c" + post-commit hook trigger
5. Job B fails (stack trace is the same as before)

However, while trying out some other things, I noticed something with the settings of Job B.
I had the hostname of the server set in the repository URL for the checkout, and the ip address set in the realm of the additional credentionals.
I set the hostname in the realm and Job B no longer failed.
Then I set the ip address for both the repository URL and realm. Job B did not fail.
So it looks like you have to specify the same host format (name or ip address) for both the repository URL and realm of additional credentials.
This does not really make sense to me, since the credential I selected is associated with a domain containing both hostname and ip address.
Bare in mind, deleting the previous build data results in a job success even if the host format is different.

One final note, I tried the above with both the patched version and unmodified version 2.2.
Job B succeeds as long as the host format for the repository URL and realm are the same.

mike.penz@netural.com (JIRA)

unread,
Mar 14, 2014, 3:07:16 AM3/14/14
to jenkinsc...@googlegroups.com
Mike Penz commented on Bug JENKINS-21785

@Daniel Beck

i just tried to build and install your changes, but they did not change anything for us.

We still get the following error:
hudson.util.IOException2: revision check failed on http://10.28.201.18/svn/xxx/Website/Config/trunk
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:226)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:169)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:739)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:900)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
at hudson.model.Run.execute(Run.java:1676)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/xxx/Website/Config/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.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: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.SVNLogClient.doLog(SVNLogClient.java:967)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)

at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:214)
... 11 more


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)
... 29 more

Our repository A is on our svn server.
On the build it checks out all externals (from different repositories, all with the same credentials on the same svn server)
It fails to fetch the changelog for an external which is in the same repository A as the main project.

The issue ONLY happens if there was a change in repository B.

I tried it without additional credentials. i tried it with additional credentials and the realm set with the ip (http://ip/)
i tried it with additional credentials and the realm set to the svn subpath (http://ip/svn/)

daniel@beckweb.net (JIRA)

unread,
Mar 14, 2014, 7:27:16 AM3/14/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

Chikigai:

So it looks like you have to specify the same host format (name or ip address) for both the repository URL and realm of additional credentials.

Yes. The realm appears to be created from the host/port the client connects to, not from something the server reports. Which makes sense considering reverse proxies etc.

This does not really make sense to me, since the credential I selected is associated with a domain containing both hostname and ip address.

The realm string you specify is used as the key in a map, and the realm string SVNKit builds is used for the lookup of the credential to use in said map. (At least that's how it works for my first patch which I still believe to use correct)

Bare in mind, deleting the previous build data results in a job success even if the host format is different.

I found out after I asked for it that this is quite obvious in the code.

One final note, I tried the above with both the patched version and unmodified version 2.2.

Thanks for letting me know, now I can revert the change.

It really appears to me that any failures with this particular exception are user error (wrong realm names).

daniel@beckweb.net (JIRA)

unread,
Mar 14, 2014, 8:01:17 AM3/14/14
to jenkinsc...@googlegroups.com

Mike Penz:

i tried it with additional credentials and the realm set with the ip (http://ip/)
i tried it with additional credentials and the realm set to the svn subpath (http://ip/svn/)

If you mean that you specified "http://ip/" and "http://ip/svn/" as realm strings: I'm pretty sure these are never valid realm strings and none of the methods I described above to find out the realm string returned these. It appears that you're simply guessing.

If you know how to read some Java: This is how they're created in the client library; and what you enter must be the exact same string:

https://github.com/jenkinsci/svnkit/blob/1.7.6-jenkins-2/svnkit/src/main/java/org/tmatesoft/svn/core/internal/io/svn/sasl/SVNSaslAuthenticator.java#L336
https://github.com/jenkinsci/svnkit/blob/1.7.6-jenkins-2/svnkit/src/main/java/org/tmatesoft/svn/core/internal/io/svn/SVNPlainAuthenticator.java#L60
https://github.com/jenkinsci/svnkit/blob/1.7.6-jenkins-2/svnkit/src/main/java/org/tmatesoft/svn/core/internal/io/svn/SVNSSHConnector.java#L76

Another way to find out the realm string if you use SVN from the command line (if you're on Linux or OS X; something similar should works on Windows as well):

find ~/.subversion/auth/svn.simple/ -type f -exec cat {} + | grep -A 2 realmstring

This will print all realm strings for which password credentials are saved by your SVN client.

soukupmi@gmail.com (JIRA)

unread,
Mar 17, 2014, 5:53:18 AM3/17/14
to jenkinsc...@googlegroups.com

Under Windows you can use findstr

findstr "<" %appdata%\Subversion\auth\svn.simple\*

unfortunately findstr is way not as flexible as grep, so you cannot print the lines following realmstring but only the line that contains it. This is why I chose to look for the "<" instead.

jenkins@mockies.de (JIRA)

unread,
Mar 17, 2014, 8:48:16 PM3/17/14
to jenkinsc...@googlegroups.com

I was able to work around the issue by adding "additional credentials" with realm "<https://server:443> VisualSVN Server" and the same credentials that is used for the module itself.

cbos.ec@gmail.com (JIRA)

unread,
Mar 20, 2014, 9:16:19 AM3/20/14
to jenkinsc...@googlegroups.com
 
Cees Bos edited a comment on Bug JENKINS-21785

We are facing the same issue as soon as there is an update in the svn:external linked folder.
At that moment we don't face the issue in the checkout or update, but we face this issue in the log determination.

When there is no change in the svn:external linked folder, then there is no issue.

cbos.ec@gmail.com (JIRA)

unread,
Mar 20, 2014, 9:16:18 AM3/20/14
to jenkinsc...@googlegroups.com
Cees Bos commented on Bug JENKINS-21785

We are facing the same issue as soon as there is an update in the svn:external linked folder.
At that moment we don't face the issue in the checkout or update, but we face this issue in the log determination.

When there is no change in in the svn:external linked folder, then there is no issue.

chikigai@java.net (JIRA)

unread,
Mar 27, 2014, 7:29:05 AM3/27/14
to jenkinsc...@googlegroups.com
chikigai commented on Bug JENKINS-21785

Although I thought I had everything fixed, it looks like I'm still facing issues with commit notifications.
I no longer get authentication errors with the actual checkout, but the commit notifications via hook scripts are randomly failing.
The log shows "Failed to handle Subversion commit notification" followed by the same authentication error details as posted before.
I've run out of ideas of where to look for possible causes.

jenkins@mockies.de (JIRA)

unread,
Mar 27, 2014, 10:29:05 AM3/27/14
to jenkinsc...@googlegroups.com

I can confirm that commit notifications via hook scripts are randomly failing for svn:externals as reported by chikigai. Without svn:externals everything seems to work as expected. In my case svn:externals point to other repositories on the same server and and the access rights do not differ from the main repository. So using the same credentials for svn:externals should work.

daniel@beckweb.net (JIRA)

unread,
Mar 27, 2014, 3:37:05 PM3/27/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

FYI my earlier fix has become PR 70 and was merged today, so using a snapshot build should resolve commit hook and subversion tagging plugin related issues.

davida2009@java.net (JIRA)

unread,
Mar 28, 2014, 9:17:05 AM3/28/14
to jenkinsc...@googlegroups.com
davida2009 commented on Bug JENKINS-21785

I am randomly getting exceptions for svn projects that include external references:

At revision 1219
At revision 5564
no change for https://<snip>/subversion/<snip>/trunk since the previous build
13:03:36 hudson.util.IOException2: revision check failed on https://<snip>

Re-running the job usually fixes the error.

I have specified the 'Additional credential' as is required. The failures occur on both Linux and Windows slaves.

I think the error cases I am experiencing are similar to some of those discussed in this thread. Please will someone summarise the issue status and tell me if there is any fix I can apply?

r.bergoin@openium.fr (JIRA)

unread,
Mar 31, 2014, 3:09:05 AM3/31/14
to jenkinsc...@googlegroups.com

Facing the same issue, and installed the latest github version with #70 pull request merged (https://github.com/jenkinsci/subversion-plugin/commit/ed6e43e04ddd15ce302b23740625ca4e69d1fead) which allows to log credentials used. The credentials are OK, so this bug might be linked to a svnkit one :
http://issues.tmatesoft.com/issue/SVNKIT-345

r.bergoin@openium.fr (JIRA)

unread,
Mar 31, 2014, 10:57:06 AM3/31/14
to jenkinsc...@googlegroups.com

Update : installing current svnkit (https://github.com/jenkinsci/svnkit/releases/tag/1.7.10) cli tools, and making a "jsvn info $REPO" and saving credentials from there make post-commits working again.
Not a good way, but it could help solving this issue temporaly waiting the 2.3 plugin version that correct it.

jenkins@mockies.de (JIRA)

unread,
Mar 31, 2014, 5:07:05 PM3/31/14
to jenkinsc...@googlegroups.com

@Daniel: using the snapshot build gives me:

Mar 31, 2014 10:09:07 AM WARNING winstone.Logger logInternal
Called getReader after getParameter ... error
Mar 31, 2014 10:09:07 AM WARNING hudson.scm.SubversionRepositoryStatus doNotifyCommit
Listener hudson.scm.SubversionRepositoryStatus$JobTriggerListenerImpl threw an uncaught exception
java.lang.NullPointerException
        at com.cloudbees.plugins.credentials.matchers.IdMatcher.<init>(IdMatcher.java:49)
        at com.cloudbees.plugins.credentials.CredentialsMatchers.withId(CredentialsMatchers.java:112)
        at hudson.scm.SubversionSCM$ModuleLocation.openRepository(SubversionSCM.java:2736)
        at hudson.scm.SubversionSCM$ModuleLocation.getUUID(SubversionSCM.java:2711)
        at hudson.scm.SubversionRepositoryStatus$JobTriggerListenerImpl.onNotify(SubversionRepositoryStatus.java:202)
        at hudson.scm.SubversionRepositoryStatus.doNotifyCommit(SubversionRepositoryStatus.java:136)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298)
        at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161)
        at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96)
        at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:120)
        at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
        at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
        at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
        at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:390)
        at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
        at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
        at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:390)
        at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
        at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
        at org.kohsuke.stapler.Stapler.invoke(Stapler.java:631)
        at org.kohsuke.stapler.Stapler.service(Stapler.java:225)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
        at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)
        at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)
        at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:96)
        at com.marvelution.jenkins.plugins.jira.filter.OAuthServletFilter.doFilter(OAuthServletFilter.java:70)
        at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
        at com.marvelution.jenkins.plugins.jira.filter.StreamsServletFilter.doFilter(StreamsServletFilter.java:84)
        at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
        at com.marvelution.jenkins.plugins.jira.filter.ApplinksServletFilter.doFilter(ApplinksServletFilter.java:90)
        at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
        at com.marvelution.jenkins.plugins.jira.oauth.OAuthFilter.doFilter(OAuthFilter.java:82)
        at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
        at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58)
        at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
        at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:88)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
        at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:174)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:79)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
        at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
        at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:46)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at winstone.RequestDispatcher.forward(RequestDispatcher.java:331)
        at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:227)
        at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
        at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
        at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
        at java.util.concurrent.FutureTask.run(Unknown Source)
        at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
 
Mar 31, 2014 10:09:07 AM INFO jenkins.scm.impl.subversion.SubversionSCMSource$ListenerImpl onNotify
Received post-commit hook from 9ac4290d-b8dc-5d40-a2b8-e322e6355784 for revision -1 on paths [trunk/BuildCfg/doxyfile.versioninfo, trunk/BuildCfg/doxyfile]
Mar 31, 2014 10:09:07 AM INFO jenkins.scm.impl.subversion.SubversionSCMSource$ListenerImpl onNotify
No subversion consumers for UUID 9ac4290d-b8dc-5d40-a2b8-e322e6355784
Mar 31, 2014 10:09:07 AM WARNING hudson.scm.SubversionRepositoryStatus doNotifyCommit
No interest in change to repository UUID 9ac4290d-b8dc-5d40-a2b8-e322e6355784 found

SVN commit hook change notifcation does not work at all for me using the snapshot build. Even if the change is not in the externals.

daniel@beckweb.net (JIRA)

unread,
Mar 31, 2014, 5:23:07 PM3/31/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

Christoph Vogtländer: With some luck only a minor issue. Will try to get an updated patch by tomorrow. Email me directly if you're willing to be the guinea pig.

daniel@beckweb.net (JIRA)

unread,
Mar 31, 2014, 5:46:05 PM3/31/14
to jenkinsc...@googlegroups.com
 
Daniel Beck edited a comment on Bug JENKINS-21785

Christoph Vogtländer:

Issue appears for me when running the following:

def p = Jenkins.instance.getItemByFullName('job-with-svn-with-externals');

p.scm.with {
  it.getProjectLocations(p).each { loc ->
        println loc
  	println loc.getUUID(p)
  }
}

This mirrors the behavior of Jenkins during the post-commit hook.

Proposed patch that resolves the issue for me (on top of PR 70):

$ git diff
diff --git a/src/main/java/hudson/scm/SubversionSCM.java b/src/main/java/hudson/scm/SubversionSCM.java
index 938b39b..75db1e1 100755
--- a/src/main/java/hudson/scm/SubversionSCM.java
+++ b/src/main/java/hudson/scm/SubversionSCM.java
@@ -2736,7 +2736,7 @@ public class SubversionSCM extends SCM implements Serializable {
                         StandardCredentials cred = CredentialsMatchers
                                 .firstOrNull(CredentialsProvider.lookupCredentials(StandardCredentials.class, context,
                                         ACL.SYSTEM, Collections.<DomainRequirement>emptyList()),
-                                        CredentialsMatchers.allOf(CredentialsMatchers.withId(credentialsId),
+                                        CredentialsMatchers.allOf(CredentialsMatchers.withId(c.getCredentialsId()),
                                                 CredentialsMatchers.anyOf(CredentialsMatchers.instanceOf(
                                                         StandardCredentials.class), CredentialsMatchers.instanceOf(
                                                         SSHUserPrivateKey.class))));

Will probably open the PR tomorrow.

daniel@beckweb.net (JIRA)

unread,
Mar 31, 2014, 6:07:05 PM3/31/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

Christoph Vogtländer (or anyone interested in a fix):

I'd appreciate if you could test this – as my original change failed to fix my original description how to reproduce the problem I'd like to get independent confirmation.

PR: https://github.com/jenkinsci/subversion-plugin/pull/74
CI build for it: https://jenkins.ci.cloudbees.com/job/plugins/job/subversion-plugin/336/

jenkins@mockies.de (JIRA)

unread,
Mar 31, 2014, 6:30:05 PM3/31/14
to jenkinsc...@googlegroups.com

Daniel Beck:

Using the new snapshot (PR74/Build 336) fixed the problem for me. At least using your script test code posted in 1 and 2. Tested the scripts with the snapshot from PR70 to confirm failure. The test with PR74 now succeedes. I will do a real commit hook test tomorrow at work. Thanks a lot for your help.

r.bergoin@openium.fr (JIRA)

unread,
Apr 1, 2014, 3:33:06 AM4/1/14
to jenkinsc...@googlegroups.com

@Daniel Just installed https://jenkins.ci.cloudbees.com/job/plugins/job/subversion-plugin/336/org.jenkins-ci.plugins$subversion/ and removed ~/.subversion that contains "static credentials" added by using jsvn. And got the issue again on externals :

Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed

Re-added credentials by doing a "jsvn info $REPO", and then post-commit works again.

daniel@beckweb.net (JIRA)

unread,
Apr 1, 2014, 4:20:08 AM4/1/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

Richard Bergoin: Not sure how many of the preceding comments you read, but please note that this fix simply adds support for "additional credentials" in some code paths that used no credentials at all. You'll still need to define credentials for the explicitly defined modules, you'll still need to add "additional credentials" in case of externals, even within the same repos as your other modules , and you need to specify the correct realm for those so they are considered at all during authentication.

If you read and understood all of the previous comments to this issue, and followed the instructions, but the problem still occurs, please post the entire stack trace, including all the "Caused by" sections. The error message alone is useless.

r.bergoin@openium.fr (JIRA)

unread,
Apr 1, 2014, 4:57:07 AM4/1/14
to jenkinsc...@googlegroups.com

@Daniel, thanks for reply, here is the log, and the CredentialsSVNAuthenticationProviderImpl logger output make me think that the credentials used for the externals are the one used for the main module (no additional module configured, as you said) :

 
Apr 01, 2014 9:24:45 AM FINE hudson.scm.CredentialsSVNAuthenticationProviderImpl
Attempting auth for URL: https://svn.company.com/repo/tags/project-1.0; Realm: <https://svn.company.com:443> SVN repository
Apr 01, 2014 9:24:45 AM WARNING hudson.scm.SubversionRepositoryStatus$JobTriggerListenerImpl onNotify
Failed to handle Subversion commit notification
org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /repo/tags/project-1.0 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.getRepositoryUUID(DAVRepository.java:148)
	at hudson.scm.SubversionSCM$ModuleLocation.getUUID(SubversionSCM.java:2712)
	at hudson.scm.SubversionRepositoryStatus$JobTriggerListenerImpl.onNotify(SubversionRepositoryStatus.java:202)
	at hudson.scm.SubversionRepositoryStatus.doNotifyCommit(SubversionRepositoryStatus.java:136)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298)
	at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161)
	at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96)
	at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:120)
	at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
	at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
	at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:390)
	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
	at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
	at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:390)
	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
	at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
	at org.kohsuke.stapler.Stapler.invoke(Stapler.java:631)
	at org.kohsuke.stapler.Stapler.service(Stapler.java:225)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494)
	at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:96)
	at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:88)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
	at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
	at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
	at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117)
	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
	at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
	at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
	at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
	at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:174)
	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
	at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:74)
	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
	at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
	at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67)
	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
	at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
	at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
	at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:46)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
	at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
	at org.eclipse.jetty.server.Server.handle(Server.java:370)
	at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
	at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:960)
	at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1021)
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
	at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
	at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)
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 hudson.scm.FilterSVNAuthenticationManager.getFirstAuthentication(FilterSVNAuthenticationManager.java:35)
	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)
	... 85 more

daniel@beckweb.net (JIRA)

unread,
Apr 1, 2014, 5:25:12 AM4/1/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

Richard: To clarify, you have one module configured, and no additional credentials? If so, you simply need to do that; externals only have "additional credentials" to work with, even when in the same repo! That log message I added to assist in determining the "realm" to enter, as some users expressed confusion about how that works.

Just add an "additional credential", use {{<https://svn.company.com:443> SVN repository}} for the realm, and choose whatever credential is appropriate for that repo, could be the same as for the configured module.

daniel@beckweb.net (JIRA)

unread,
Apr 1, 2014, 5:25:12 AM4/1/14
to jenkinsc...@googlegroups.com
 
Daniel Beck edited a comment on Bug JENKINS-21785

r.bergoin@openium.fr (JIRA)

unread,
Apr 1, 2014, 5:39:05 AM4/1/14
to jenkinsc...@googlegroups.com

To clarify, you have one module configured, and no additional credentials? : yes.

The realm for the external is (I think) the same that the realm of the "main" module, for exemple, an app have an external to a library tag :
https://svn.company.com/app/trunk
have
https://svn.company.com/lib/tags/project-1.0
as externals

Shouldn't main module credentials be applied, as both realms are "<https://svn.company.com:443> SVN repository" ?

soukupmi@gmail.com (JIRA)

unread,
Apr 1, 2014, 6:27:06 AM4/1/14
to jenkinsc...@googlegroups.com

Shouldn't main module credentials be applied, as both realms are "<https://svn.company.com:443> SVN repository" ?

should
But ain't: comment-195699
this is why there exists this bug entry after all...

daniel@beckweb.net (JIRA)

unread,
Apr 1, 2014, 6:47:05 AM4/1/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

Richard:

Should it? Possibly.
Does it? No.

Which many of the preceding comments mention (e.g. 1 2 3 4).

r.bergoin@openium.fr (JIRA)

unread,
Apr 1, 2014, 8:39:06 AM4/1/14
to jenkinsc...@googlegroups.com

I was thinking the PR 70 will solve this issue (I misundertood the log and think that it inform the "realm" which will be used to the connection). I can test this issue (as previously with PR 74), if the "possibly" can be assume to be "yes" (but who can decide of this...). From my point of view, credentials are "server based" for continuous, but it could be "repository based" (subpath of a server).
Maybe a "FINE" logging of username used to connect to a repository can be interesting (for debugging purpose).

jens.rosenthal@compcom.de (JIRA)

unread,
Apr 1, 2014, 8:47:05 AM4/1/14
to jenkinsc...@googlegroups.com

@Richard: I believe that the credentials have to be "repository based"... Just think of a huge company with many project teams and a fine grained access control for all the repositories hosted on one (or more) SVN server(s).

Matching the URL (of the external) - e.g. https://svn.server.company:443/reporoot/repo/my/external - against a realm string - e.g. https://svn.server.company:443/reporoot/repo - might well suffice for this to work.

davida2009@java.net (JIRA)

unread,
Apr 1, 2014, 8:51:07 AM4/1/14
to jenkinsc...@googlegroups.com
davida2009 commented on Bug JENKINS-21785

I am running Jenkins 1.552 on a Linux master. I have installed svn plugin '2.3-SNAPSHOT(private-03/31/2-14 18:05-jenkins'.
I have a job that runs on a Windows slave that polls a svn repo and does a Visual Studio C++ build if a change is detected. The svn repo has an external link to another svn repo. I have specified an 'additional credential' for the external (I believe correctly). Jenkins gives the following exception when I commit a change to the external repo and run the Jenkins job:

Apr 01, 2014 1:36:42 PM WARNING hudson.ExpressionFactory2$JexlExpression evaluateCaught exception evaluating: it.transientActions in /jenkins/job/Zodiac_VS2010_Osiris_TI/110/. Reason: java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException


at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)

at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125)
at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314)
at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185)
at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75)
at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83)
at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57)
at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51)
at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80)
at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:74)
at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:58)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120)
at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98)
at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81)
at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:147)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120)
at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81)
at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63)
at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:53)
at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:112)
at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:717)


at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:390)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)

at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:248)


at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)

at org.kohsuke.stapler.Stapler.invoke(Stapler.java:631)
at org.kohsuke.stapler.Stapler.service(Stapler.java:225)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:96)

at jenkins.metrics.impl.MetricsFilter.doFilter(MetricsFilter.java:117)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:202)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:180)
at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:85)
at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:90)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)


at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:88)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:174)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)

at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:79)


at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:46)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:370)
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)

at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949)
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)


at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)


at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Caused by: java.lang.NullPointerException
at com.chikli.hudson.plugin.naginator.NaginatorActionFactory.createFor(NaginatorActionFactory.java:20)
at hudson.model.Run.getTransientActions(Run.java:357)
... 129 more

Apr 01, 2014 1:36:44 PM WARNING hudson.ExpressionFactory2$JexlExpression evaluateCaught exception evaluating: it.transientActions in /jenkins/job/Zodiac_VS2010_Osiris_TI/110/console. Reason: java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException


at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)

at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125)
at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314)
at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185)
at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75)
at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83)
at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57)
at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51)
at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80)
at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:74)
at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:58)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120)
at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98)
at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81)
at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:147)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120)
at org.kohsuke.stapler.jelly.CompressTag.doTag(CompressTag.java:44)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81)
at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63)
at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:53)
at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:95)


at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:390)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)

at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:248)


at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)

at org.kohsuke.stapler.Stapler.invoke(Stapler.java:631)
at org.kohsuke.stapler.Stapler.service(Stapler.java:225)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:96)

at jenkins.metrics.impl.MetricsFilter.doFilter(MetricsFilter.java:117)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:202)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:180)
at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:85)
at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:90)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)


at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:88)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:174)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)

at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:79)


at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:46)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:370)
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)

at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949)
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)


at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)


at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Caused by: java.lang.NullPointerException
at com.chikli.hudson.plugin.naginator.NaginatorActionFactory.createFor(NaginatorActionFactory.java:20)
at hudson.model.Run.getTransientActions(Run.java:357)
... 129 more

jenkins@mockies.de (JIRA)

unread,
Apr 1, 2014, 9:59:06 AM4/1/14
to jenkinsc...@googlegroups.com
 
Christoph Vogtländer edited a comment on Bug JENKINS-21785

Daniel Beck:

Using the new snapshot (PR74/Build 336) fixed the problem for me. At least using your script test code posted in 1 and 2. Tested the scripts with the snapshot from PR70 to confirm failure. The test with PR74 now succeedes.

Also successfully tested with "real" commit hook notification. There are no trace messages left in the log and jobs are triggered correctly. Thanks a lot for your help.

r.bergoin@openium.fr (JIRA)

unread,
Apr 1, 2014, 10:08:05 AM4/1/14
to jenkinsc...@googlegroups.com

@Jens, Ok for repo base credentials, in fact this is also that we have, I would add a "global credentials" to not have to reconfigure each jobs using this external (more than 30), but the global credentials is domain based (e.g. hostname, so only one global credential for svn.company.com)

Note that we also have CI for our internal libraries, so the credentials are already entered in another job.

daniel@beckweb.net (JIRA)

unread,
Apr 1, 2014, 10:13:06 AM4/1/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

Richard: It may be possible, but it's not currently implemented this way (admittedly, the current solution seems a bit weird). If PR70+PR74 work, then only an issue of convenience / redundancy in configuration is left.

David: The error seems to be completely unrelated. I suggest you open a new issue for that.

Anyone able to confirm that PR74 works?

soukupmi@gmail.com (JIRA)

unread,
Apr 1, 2014, 10:15:06 AM4/1/14
to jenkinsc...@googlegroups.com

@Richard:
you can use the same method that I used to reconfigure our 20+ jobs:
edit the xml files directly and restart the server as described in comment-196380

mike.penz@netural.com (JIRA)

unread,
Apr 1, 2014, 10:26:05 AM4/1/14
to jenkinsc...@googlegroups.com
Mike Penz commented on Bug JENKINS-21785

I've also installed the snapshot plugin, i've also set the additional credentials, without any luck. As soon as there's a change in one of the externals it fails.

hudson.util.IOException2: revision check failed on http://server/svn/repo/...
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:189)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:739)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:900)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1320)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:518)
at hudson.model.Run.execute(Run.java:1688)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/repo/... 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.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: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.SVNLogClient.doLog(SVNLogClient.java:967)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:177)
... 11 more


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)

... 29 more

we checkout two modules each with their own credentials
http://server/svn/repo/folder1... with credentials1
http://server/svn/repo/folder2... with credentials1

and i add additional credentials with realm
http://server/svn/repo with credentials1

i've also tried additional credentials with realm
http://server/ with credentials1

(the credentials1 are all the same)

soukupmi@gmail.com (JIRA)

unread,
Apr 1, 2014, 10:36:05 AM4/1/14
to jenkinsc...@googlegroups.com

@[~Mike Penz]
make sure you entered the realm as described in comment-197898 and comment-196458, not only the url of the repository - it should work for you, too.

<https://svn.company.com:443> SVN repository
This message is automatically generated by JIRA.

soukupmi@gmail.com (JIRA)

unread,
Apr 1, 2014, 10:38:06 AM4/1/14
to jenkinsc...@googlegroups.com
 
michael soukup edited a comment on Bug JENKINS-21785


make sure you entered the realm as described in comment-197898 and comment-196458, not only the url of the repository - it should work for you, too.

<https://svn.company.com:443> SVN repository

mike.penz@netural.com (JIRA)

unread,
Apr 1, 2014, 10:40:06 AM4/1/14
to jenkinsc...@googlegroups.com
 
Mike Penz edited a comment on Bug JENKINS-21785

I've also installed the snapshot plugin, i've also set the additional credentials, without any luck. As soon as there's a change in one of the externals it fails.
This message is automatically generated by JIRA.

mike.penz@netural.com (JIRA)

unread,
Apr 1, 2014, 11:19:08 AM4/1/14
to jenkinsc...@googlegroups.com
Mike Penz commented on Bug JENKINS-21785

@michael soukup

Ok i was now able to solve it too. You were right that you have to define the realm including the brackets and the name. i always thought it should work if you just define https://svn.company.com:443
Thanks for the help

any solution how to define this as default? we have 100+ builds and almost each of those has externals.

mike.penz@netural.com (JIRA)

unread,
Apr 1, 2014, 11:21:10 AM4/1/14
to jenkinsc...@googlegroups.com
 
Mike Penz edited a comment on Bug JENKINS-21785

Ok i was now able to solve it too. You were right that you have to define the realm including the brackets and the name. i always thought it should work if you just define https://svn.company.com:443
Thanks for the help

any solution how to define this as default? we have 100+ builds and almost each of those has externals.

mike.penz@netural.com (JIRA)

unread,
Apr 1, 2014, 11:21:10 AM4/1/14
to jenkinsc...@googlegroups.com

Ok i was now able to solve it too. You were right that you have to define the realm including the brackets and the name. i always thought it should work if you just define https://svn.company.com:443
Thanks for the help

any solution how to define this as default? we have 100+ builds and almost each of those has externals.

davida2009@java.net (JIRA)

unread,
Apr 1, 2014, 11:23:05 AM4/1/14
to jenkinsc...@googlegroups.com
davida2009 commented on Bug JENKINS-21785

Hi Daniel

Sorry, I pasted in the wrong exception. I really am getting one relevant to this issue (see below). I am running your snapshot. The exception is random - sometimes the update succeeds, sometimes it doesn't. This time I used a clean workspace, to clear any cached credentials.

David

At revision 1231
At revision 5573
no change for https://172.29.68.12/subversion/zodiac/trunk since the previous build
hudson.util.IOException2: revision check failed on https://172.29.68.12/subversion/Osiris/trunk/Source/Osiris/include


at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:189)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:739)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:900)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1320)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:518)
at hudson.model.Run.execute(Run.java:1688)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)

Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /subversion/Osiris/trunk/Source/Osiris/include failed
This message is automatically generated by JIRA.

mike.penz@netural.com (JIRA)

unread,
Apr 1, 2014, 11:55:09 AM4/1/14
to jenkinsc...@googlegroups.com
Mike Penz commented on Bug JENKINS-21785

davida2009 ok it seems you have the exact same issue we had.

Try to add additinal credentials. It's really important that you use
the correct realm.

The realm in our case is "<http://server:port> SVN Server Name" <-- without "
After migrating to the new subversion plugin the name of the old credentials
was automatically set to the realm of the svn server try to using this one.
our automatically upgraded credentials had a name like
"buildmaster/****** (<http://server:port> SVN Server Name)" just remove the
stuff before and the brackets.

davida2009@java.net (JIRA)

unread,
Apr 1, 2014, 12:02:05 PM4/1/14
to jenkinsc...@googlegroups.com
davida2009 commented on Bug JENKINS-21785

Mike, thanks for your help. I have specified 'additional credentials'. However, until today I had specified a realm of:

CollabNet Subversion Repository

which we got from our server configuration. Today I added the url:

<https://<snip>/subversion:443> CollabNet Subversion Repository

but that made no difference. I still get the exception.

Unfortunately there seems to be no documentation in Jenkins about this. Until recently I was completely unaware of the concept of 'realm' in Subversion.

daniel@beckweb.net (JIRA)

unread,
Apr 1, 2014, 12:57:06 PM4/1/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-21785

davida: Skip the local path /subversion. Search through my older comments, there's several ways described how you can find out the realm.

mike.penz@netural.com (JIRA)

unread,
Apr 2, 2014, 2:00:06 AM4/2/14
to jenkinsc...@googlegroups.com
Mike Penz commented on Bug JENKINS-21785

@davida2009 i've wrote a small description for others who create builds. perhaps it's useful for someone else too. (the part 4.1. is the important one for you)

how to set additional credentials
1. open the build configuration
2. scroll down to the source-code-management section
3. click on the "Add additional credentials..." button
4. define as realm the specific identifier for our svn server --> (<http://ip:port> Company Subversion Repository) <-- without the "(", ")" brackets
4.1. if it should work for a different svn you need to use the realm of this server
4.2. checkout a repo on this server via the command-line --> svn --username {username} --password {password} checkout http://ip:port/svn/repo <-- you can cancel this after it has started the checkout
4.3. read all realms available on your mac with this cmd --> "find ~/.subversion/auth/svn.simple/ -type f -exec cat {} + | grep -A 2 realmstring"
5. select the credentials --> "buildmaster/****** (<http://ip:port> Company Subversion Repository)"
6. save and be happy!

mike.penz@netural.com (JIRA)

unread,
Apr 2, 2014, 2:04:05 AM4/2/14
to jenkinsc...@googlegroups.com
 
Mike Penz edited a comment on Bug JENKINS-21785

@davida2009 i've wrote a small description for others who create builds. perhaps it's useful for someone else too. (the part 4.1. is the important one for you)

how to set additional credentials
1. open the build configuration
2. scroll down to the source-code-management section
3. click on the "Add additional credentials..." button
4. define as realm the specific identifier for our svn server --> (<http://ip:port> Company Subversion Repository) <-- without the "(", ")" brackets
4.1. if it should work for a different svn you need to use the realm of this server
4.2. checkout a repo on this server via the command-line --> svn --username {username} --password {password} checkout http://ip:port/svn/repo <-- you can cancel this after it has started the checkout

4.2.1. other solutions to get the realmstring: comment-196510


4.3. read all realms available on your mac with this cmd --> "find ~/.subversion/auth/svn.simple/ -type f -exec cat {} + | grep -A 2 realmstring"
5. select the credentials --> "buildmaster/****** (<http://ip:port> Company Subversion Repository)"
6. save and be happy!

mike.penz@netural.com (JIRA)

unread,
Apr 2, 2014, 2:06:06 AM4/2/14
to jenkinsc...@googlegroups.com

@davida2009 i've wrote a small description for others who create builds. perhaps it's useful for someone else too. (the part 4.1. is the important one for you)

how to set additional credentials
1. open the build configuration
2. scroll down to the source-code-management section
3. click on the "Add additional credentials..." button
4. define as realm the specific identifier for our svn server --> (<http://ip:port> Company Subversion Repository) <-- without the "(", ")" brackets
4.1. if it should work for a different svn you need to use the realm of this server
4.2. checkout a repo on this server via the command-line --> svn --username {username} --password {password} checkout http://ip:port/svn/repo <-- you can cancel this after it has started the checkout

4.2.1. other solutions to get the realmstring: comment-196510, comment-196730, comment-196903


4.3. read all realms available on your mac with this cmd --> "find ~/.subversion/auth/svn.simple/ -type f -exec cat {} + | grep -A 2 realmstring"
5. select the credentials --> "buildmaster/****** (<http://ip:port> Company Subversion Repository)"
6. save and be happy!

mike.penz@netural.com (JIRA)

unread,
Apr 2, 2014, 3:00:05 AM4/2/14
to jenkinsc...@googlegroups.com

@davida2009 i've wrote a small description for others who create builds. perhaps it's useful for someone else too. (the part 4.1. is the important one for you)

how to set additional credentials
1. open the build configuration
2. scroll down to the source-code-management section
3. click on the "Add additional credentials..." button
4. define as realm the specific identifier for our svn server --> (<http://ip:port> Company Subversion Repository) <-- without the "(", ")" brackets
4.1. if it should work for a different svn you need to use the realm of this server
4.2. checkout a repo on this server via the command-line --> svn --username {username} --password {password} checkout http://ip:port/svn/repo <-- you can cancel this after it has started the checkout

4.3. read all realms available on your mac with this cmd --> "find ~/.subversion/auth/svn.simple/ -type f -exec cat {} + | grep -A 2 realmstring"

4.3.1. other solutions to get the realmstring: comment-196510, comment-196730, comment-196903
4.3.2. there's also another option to get the realmstring. on a pc which was not connected to the svn before, do the following in the therminal:
"*svn info http://ip:port/pathtorepo*" --> this will output something like "*Authentication realm: <http://ip:port> Company Subversion Repository*"


5. select the credentials --> "buildmaster/****** (<http://ip:port> Company Subversion Repository)"
6. save and be happy!

It is loading more messages.
0 new messages