Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-22542

Subversion polling not work with externals or variables in URL - E200015: No credential to try.

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Blocker
    • Resolution: Not A Defect
    • Component/s: subversion-plugin
    • Environment:
    • Similar Issues:

      Description

      While the build itself woks fine, with subversion polling, I got E200015 error, even with correct Additional Credentials configured. This happens only for projects with variables in repo URL (but they are substituted correctly) or for repos with externals.

      variables testcase:

      Started on Apr 9, 2014 9:32:59 AM
      Received SCM poll call on windows7 for DUMMY on 9.4.2014 9:32:54
      ERROR: Failed to check repository revision for svn+ssh://jenkins@XXX.com/svn/XXX/trunk
      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.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46)
      at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31)
      at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
      at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
      at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
      at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461)
      at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1267)
      at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:78)
      at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26)
      at hudson.remoting.UserRequest.perform(UserRequest.java:118)
      at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      at hudson.remoting.Request$2.run(Request.java:326)
      at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      at java.util.concurrent.FutureTask.run(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      at hudson.remoting.Engine$1$1.run(Engine.java:63)
      at java.lang.Thread.run(Unknown Source)
      Done. Took 56 ms
      No changes

      For externals, the error seems the same:

      Started on Apr 9, 2014 9:34:59 AM
      Received SCM poll call on windows7 for DUMMY2 on 9.4.2014 9:34:54
      ERROR: Failed to check repository revision for svn+ssh://XXX.com/svn/XXX/trunk/EXT_REF
      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.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46)
      at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31)
      at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
      at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
      at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
      at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461)
      at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1267)
      at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:78)
      at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26)
      at hudson.remoting.UserRequest.perform(UserRequest.java:118)
      at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      at hudson.remoting.Request$2.run(Request.java:326)
      at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      at java.util.concurrent.FutureTask.run(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      at hudson.remoting.Engine$1$1.run(Engine.java:63)
      at java.lang.Thread.run(Unknown Source)
      svn+ssh://XXX.com/svn/XXX/trunk is at revision 675
      ERROR: Failed to check repository revision for svn+ssh://XXX.com/svn/XXX/trunk/EXT_REF/src
      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.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46)
      at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31)
      at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
      at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
      at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
      at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461)
      at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1267)
      at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:78)
      at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26)
      at hudson.remoting.UserRequest.perform(UserRequest.java:118)
      at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      at hudson.remoting.Request$2.run(Request.java:326)
      at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      at java.util.concurrent.FutureTask.run(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      at hudson.remoting.Engine$1$1.run(Engine.java:63)
      at java.lang.Thread.run(Unknown Source)
      Done. Took 93 ms
      No changes

        Attachments

          Issue Links

            Activity

            kasparek T K created issue -
            kasparek T K made changes -
            Field Original Value New Value
            Attachment plug-vers.png [ 25672 ]
            Environment CentOS 6 master, Win7 64bit, CentOS 5 slaves. CentOS 6 master, Win7 64bit, CentOS 5 slaves.

            Jenkins ver. 1.558

            subversion plugin: 2.3-SNAPSHOT (private-04/07/2014 06:29-jenkins)
            credentials plugin: 1.10
            (other plugins via screenshot)
            kasparek T K made changes -
            Description While the build itself woks fine, with subversion polling, I got E200015 error, even with correct Additional Credentials configured. This happens only for projects with variables in repo URL (but they are substituted correctly) or for repos with extrenals.

            variables testcase:


            Started on Apr 9, 2014 9:32:59 AM
            Received SCM poll call on windows7 for DUMMY on 9.4.2014 9:32:54
            ERROR: Failed to check repository revision for svn+ssh://jenkins@XXX.com/svn/XXX/trunk
            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.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46)
            at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31)
            at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
            at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
            at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
            at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461)
            at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1267)
            at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:78)
            at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26)
            at hudson.remoting.UserRequest.perform(UserRequest.java:118)
            at hudson.remoting.UserRequest.perform(UserRequest.java:48)
            at hudson.remoting.Request$2.run(Request.java:326)
            at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
            at java.util.concurrent.FutureTask.run(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
            at hudson.remoting.Engine$1$1.run(Engine.java:63)
            at java.lang.Thread.run(Unknown Source)
            Done. Took 56 ms
            No changes


            For externals, the error seems the same:


            Started on Apr 9, 2014 9:34:59 AM
            Received SCM poll call on windows7 for DUMMY2 on 9.4.2014 9:34:54
            ERROR: Failed to check repository revision for svn+ssh://XXX.com/svn/XXX/trunk/EXT_REF
            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.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46)
            at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31)
            at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
            at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
            at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
            at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461)
            at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1267)
            at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:78)
            at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26)
            at hudson.remoting.UserRequest.perform(UserRequest.java:118)
            at hudson.remoting.UserRequest.perform(UserRequest.java:48)
            at hudson.remoting.Request$2.run(Request.java:326)
            at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
            at java.util.concurrent.FutureTask.run(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
            at hudson.remoting.Engine$1$1.run(Engine.java:63)
            at java.lang.Thread.run(Unknown Source)
            svn+ssh://XXX.com/svn/XXX/trunk is at revision 675
            ERROR: Failed to check repository revision for svn+ssh://XXX.com/svn/XXX/trunk/EXT_REF/src
            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.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46)
            at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31)
            at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
            at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
            at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
            at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461)
            at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1267)
            at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:78)
            at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26)
            at hudson.remoting.UserRequest.perform(UserRequest.java:118)
            at hudson.remoting.UserRequest.perform(UserRequest.java:48)
            at hudson.remoting.Request$2.run(Request.java:326)
            at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
            at java.util.concurrent.FutureTask.run(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
            at hudson.remoting.Engine$1$1.run(Engine.java:63)
            at java.lang.Thread.run(Unknown Source)
            Done. Took 93 ms
            No changes
            While the build itself woks fine, with subversion polling, I got E200015 error, even with correct Additional Credentials configured. This happens only for projects with variables in repo URL (but they are substituted correctly) or for repos with externals.

            variables testcase:


            Started on Apr 9, 2014 9:32:59 AM
            Received SCM poll call on windows7 for DUMMY on 9.4.2014 9:32:54
            ERROR: Failed to check repository revision for svn+ssh://jenkins@XXX.com/svn/XXX/trunk
            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.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46)
            at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31)
            at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
            at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
            at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
            at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461)
            at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1267)
            at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:78)
            at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26)
            at hudson.remoting.UserRequest.perform(UserRequest.java:118)
            at hudson.remoting.UserRequest.perform(UserRequest.java:48)
            at hudson.remoting.Request$2.run(Request.java:326)
            at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
            at java.util.concurrent.FutureTask.run(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
            at hudson.remoting.Engine$1$1.run(Engine.java:63)
            at java.lang.Thread.run(Unknown Source)
            Done. Took 56 ms
            No changes


            For externals, the error seems the same:


            Started on Apr 9, 2014 9:34:59 AM
            Received SCM poll call on windows7 for DUMMY2 on 9.4.2014 9:34:54
            ERROR: Failed to check repository revision for svn+ssh://XXX.com/svn/XXX/trunk/EXT_REF
            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.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46)
            at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31)
            at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
            at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
            at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
            at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461)
            at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1267)
            at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:78)
            at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26)
            at hudson.remoting.UserRequest.perform(UserRequest.java:118)
            at hudson.remoting.UserRequest.perform(UserRequest.java:48)
            at hudson.remoting.Request$2.run(Request.java:326)
            at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
            at java.util.concurrent.FutureTask.run(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
            at hudson.remoting.Engine$1$1.run(Engine.java:63)
            at java.lang.Thread.run(Unknown Source)
            svn+ssh://XXX.com/svn/XXX/trunk is at revision 675
            ERROR: Failed to check repository revision for svn+ssh://XXX.com/svn/XXX/trunk/EXT_REF/src
            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.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46)
            at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31)
            at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
            at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
            at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
            at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461)
            at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1267)
            at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:78)
            at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26)
            at hudson.remoting.UserRequest.perform(UserRequest.java:118)
            at hudson.remoting.UserRequest.perform(UserRequest.java:48)
            at hudson.remoting.Request$2.run(Request.java:326)
            at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
            at java.util.concurrent.FutureTask.run(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
            at hudson.remoting.Engine$1$1.run(Engine.java:63)
            at java.lang.Thread.run(Unknown Source)
            Done. Took 93 ms
            No changes
            kasparek T K made changes -
            Environment CentOS 6 master, Win7 64bit, CentOS 5 slaves.

            Jenkins ver. 1.558

            subversion plugin: 2.3-SNAPSHOT (private-04/07/2014 06:29-jenkins)
            credentials plugin: 1.10
            (other plugins via screenshot)
            CentOS 6 64bit master, Win7 64bit, CentOS 5 64bit slaves.

            Jenkins ver. 1.558

            subversion plugin: 2.3-SNAPSHOT (private-04/07/2014 06:29-jenkins)
            credentials plugin: 1.10
            (other plugins via screenshot)
            Hide
            gregcovertsmith Greg Smith added a comment -

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

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

            Show
            gregcovertsmith Greg Smith added a comment - This is occurring for us too – Ubuntu master, Windows slaves. The first build of a clean workspace works. Any following builds fail on the revision check for any externs in the svn tree.
            Show
            kasparek T K added a comment - Still the same with https://jenkins.ci.cloudbees.com/job/plugins/job/subversion-plugin/341/org.jenkins-ci.plugins$subversion/ and jenkins 1.560
            Hide
            kasparek T K added a comment -

            Still the same with subversion-plugin 2.3 and jenkins 1.562

            Show
            kasparek T K added a comment - Still the same with subversion-plugin 2.3 and jenkins 1.562
            Hide
            wael Wael Darwich added a comment -

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

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

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

            Show
            wael Wael Darwich added a comment - I am getting the same using Jenkins ver. 1.562 and Subversion Plug-in 2.3 When I use the full URL it works ok, but when I use $SVN_TAG parameter with default trunk value I get: ERROR: Failed to check repository revision for https://subversion.assembla.com/svn/???/trunk org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/???/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461) at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1267) at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:78) at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26) at hudson.remoting.LocalChannel.call(LocalChannel.java:45) at hudson.scm.SubversionSCM.compareRemoteRevisionWith(SubversionSCM.java:1452) at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:357) at hudson.scm.SCM.poll(SCM.java:374) at hudson.model.AbstractProject._poll(AbstractProject.java:1427) at hudson.model.AbstractProject.poll(AbstractProject.java:1330) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:466) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:495) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32) at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:694) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more
            Hide
            kasparek T K added a comment -

            Still the same with subversion plugin 2.4 and jenkins 1.563

            Show
            kasparek T K added a comment - Still the same with subversion plugin 2.4 and jenkins 1.563
            Hide
            alex_ouzounis Alex Ouzounis added a comment -

            seeing the same issue here as well

            Show
            alex_ouzounis Alex Ouzounis added a comment - seeing the same issue here as well
            Hide
            danielbeck Daniel Beck added a comment -

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

            Show
            danielbeck Daniel Beck added a comment - Has this ever worked? If the URL is modified by a parameter, how could polling work successfully?
            Hide
            kasparek T K added a comment -

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

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

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

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

            Thanks. Closing.

            Show
            kasparek T K added a comment - After a discussion with Daniel Beck, we were able to find a setup where both variables and externals work both for polling and for the actual build for svn+ssh repositories: Simple: use "Additional Credentials" with realm svn+ssh://SERVER_NAME More complex: see the code referenced in https://issues.jenkins-ci.org/browse/JENKINS-21785?focusedCommentId=196730page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-196730 the command mentioned there seems not to work wor newer subversion clients. Thanks. Closing.
            Hide
            kasparek T K added a comment - - edited

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

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

            Show
            kasparek T K added a comment - - edited solution checked with: Jenkins 1.568 Credentials Plugin 1.14 SSH Credentials Plugin 1.7.1 Subversion Plug-in 2.4 Simple: for svn+ssh repos, use additional credentials with realm svn+ssh://SERVER_NAME
            kasparek T K made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Hide
            danielbeck Daniel Beck added a comment -

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

            Show
            danielbeck Daniel Beck added a comment - That 'Additional Credentials' is required for a default location does not make sense. It's only a workaround, the bug remains.
            danielbeck Daniel Beck made changes -
            Resolution Fixed [ 1 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            Hide
            guya65 Guy Attrill added a comment - - edited

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

            Show
            guya65 Guy Attrill added a comment - - edited The solution does work but the logging needs improving to show which job is trying to access the external We have several hundred jobs and knowing which one is causing the problem is nearly impossible to work out.
            Hide
            danielbeck Daniel Beck added a comment -

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

            Show
            danielbeck Daniel Beck added a comment - Guy: Workaround: fgrep on the master for the error message in the scm-polling.log files in job directories.
            Hide
            hjen Jennifer Hofmeister added a comment - - edited

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

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

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

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

            First two checkouts succeeded, last two didn't.

            Show
            hjen Jennifer Hofmeister added a comment - - edited I've been experiencing the error with every checkout attempt, and it's persistent. Windows 7 master and slaves. Jenkins 1.565.2 and Subversion 2.4.3. I decided to upgrade from 1.561/2.0 after encountering some SVN external issues (J refusing to check out and then complaining things were missing). Although it seems like a pure Subversion issue, downgrading Subversion plugin to 2.0 and 1.5.4 didn't help. Eventually, I upgraded it back to 2.4.3 and manually reconfigured all affected jobs in the above way. The error keeps recurring. Edit: I found out that Jenkins sometimes tries to connect to the SVN server without actually giving credentials. Here's from the svn server's connection log: " 190.10.210.20 - jenkins [25/Sep/2014:15:09:06 +0200] ... 190.10.210.20 - jenkins [25/Sep/2014:15:09:06 +0200] ... 190.10.210.20 - - [25/Sep/2014:15:09:06 +0200] ... 190.10.210.20 - - [25/Sep/2014:15:09:06 +0200] ... First two checkouts succeeded, last two didn't.
            jglick Jesse Glick made changes -
            Labels credentials subversion credentials
            Component/s credentials [ 16523 ]
            Hide
            hjen Jennifer Hofmeister added a comment -

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

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

            Hi,

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

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

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

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

            Show
            tcb T.-C. B. added a comment - Hi, don't know if this may help, but we had other issues after upgrading svn-plugin. (handled somewhere here in another solved issue) we solved our problems this way (don't remember details at the moment, but that's the direction we went): svn-plugin 2.3 reworked jenkins configuration: added credentials in jenkins configuration for matching svn location (not that intuitive...) finally we added svn-credentials for native svn (svn simple!) in home of user running jenkins, on master and slave machines this solved our issues, don't know if this might help you solving yours, but I hope it gives you some point to start with
            Hide
            hjen Jennifer Hofmeister added a comment - - edited

            Thanks a lot!

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

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

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

            Show
            hjen Jennifer Hofmeister added a comment - - edited Thanks a lot! Actually, I upgraded Jenkins to 1.580 two days ago (because of the SVN trouble, I preferred to stick with the stable versions). And it seems that the problem is now "gone" ... or at least, in the state as described above, meaning it does occur but not recur, which seems heavenly after many many weeks of pain. Just for the record, I logged all outgoing Jenkins connections to SVN, namely svnkit-network and hudson.scm.CredentialsSVNAuthenticationProviderImpl, but I couldn't find anything unusual. Welp. Seems there is no explanation, but at least a solution!
            Hide
            hjen Jennifer Hofmeister added a comment -

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

            Show
            hjen Jennifer Hofmeister added a comment - Sorry, problem keeps coming back. Maybe it's because I'm using https?
            Hide
            tcb_xy Tim-Christian Bloss added a comment -

            Interesting aspect.

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

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

            Show
            tcb_xy Tim-Christian Bloss added a comment - Interesting aspect. Java 7 seems to have some issues since those SSL-Updates of last days/weeks. In some cases regarding SNI and SSL, especially when combined, Java 8 may be an option to try for master and slaves. Another problem may be Windows updates, as some parts like smb/ad protocols get updated now and then and therefore some apache httpd modules might need an update for proper authentication/authorization against security realm/domain.
            borzh Borzh Borzhovich made changes -
            Link This issue duplicates JENKINS-21785 [ JENKINS-21785 ]
            Hide
            borzh Borzh Borzhovich added a comment -

            STEPS TO RESOLVE THIS ISSUE ON LINUX

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

            REMOVE ALL SAVED CREDENTIALS ON YOUR LOCAL COMPUTER (NOT SERVER):
                rm -rf ~/.subversion/auth
            
            ON YOUR LOCAL COMPUTER CHECKOUT REMOTE TRUNK:
                svn checkout https://your_svn_server:your_port/your_trunk
            
            SVN WILL ASK FOR CREDENTIALS, SAVE THEM LOCALLY. THEY WILL APPEAR IN NEW FILE UNDER ~/.subversion/auth/svn.simple:
                ls ~/.subversion/auth/svn.simple
            
            OPEN THIS FILE TO GET YOUR SERVER REALM:
                cat ~/.subversion/auth/svn.simple/ce8afc0996c10bf115408332b027d724
            
            COPY YOUR SERVER REALM 2 LINES BELOW svn:realmstring, FOR EXAMPLE:
                svn:realmstring
                V 56
                <https://your_svn_server:your_port/your_trunk> Subversion Repositories            <--- THIS ONE IS YOUR SERVER REALM
            
            CONFIGURE YOU JENKINS JOB -> PRESS "ADD ADDITIONAL CREDENTIALS":
                SET "Realm" TO COPIED STRING, I.E: <https://your_svn_server:your_port/your_trunk> Subversion Repositories
                PROVIDE VALID "Credentials"
            
            VOILA! 
            HOPE THIS HELPS.
            
            Show
            borzh Borzh Borzhovich added a comment - STEPS TO RESOLVE THIS ISSUE ON LINUX ==================================== REMOVE ALL SAVED CREDENTIALS ON YOUR LOCAL COMPUTER (NOT SERVER): rm -rf ~/.subversion/auth ON YOUR LOCAL COMPUTER CHECKOUT REMOTE TRUNK: svn checkout https://your_svn_server:your_port/your_trunk SVN WILL ASK FOR CREDENTIALS, SAVE THEM LOCALLY. THEY WILL APPEAR IN NEW FILE UNDER ~/.subversion/auth/svn.simple: ls ~/.subversion/auth/svn.simple OPEN THIS FILE TO GET YOUR SERVER REALM: cat ~/.subversion/auth/svn.simple/ce8afc0996c10bf115408332b027d724 COPY YOUR SERVER REALM 2 LINES BELOW svn:realmstring, FOR EXAMPLE: svn:realmstring V 56 <https://your_svn_server:your_port/your_trunk> Subversion Repositories <--- THIS ONE IS YOUR SERVER REALM CONFIGURE YOU JENKINS JOB -> PRESS "ADD ADDITIONAL CREDENTIALS": SET "Realm" TO COPIED STRING, I.E: <https://your_svn_server:your_port/your_trunk> Subversion Repositories PROVIDE VALID "Credentials" VOILA! HOPE THIS HELPS.
            Hide
            danielbeck Daniel Beck added a comment -

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

            Show
            danielbeck Daniel Beck added a comment - ... which is basically what the comment from 27/Jun/14 8:01 AM states ( JENKINS-21785 is the original 'Additional Credentials' issue).
            Hide
            hmf Hans Marggraff added a comment - - edited

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

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

            Show
            hmf Hans Marggraff added a comment - - edited It is still there in 2015. Jenkins version 1594, Credentials Plugin 1.20, subversion plugin 2.5 The error message is new: It is now Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. Additional credentials as suggested above have been added. And there is the question why they are needed in the first place if the externals are in the same repository (realm). For me this is a blocker. It makes Jenkins the wrong tool to use with Subversion-Externals.
            hmf Hans Marggraff made changes -
            Priority Major [ 3 ] Blocker [ 1 ]
            Hide
            danielbeck Daniel Beck added a comment -

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

            Show
            danielbeck Daniel Beck added a comment - Hans: Please provide substantially more information on how to reproduce this issue. How is the job configured? How is the SVN server configured? Did it work before, and if so, what changed? Does it work when downgrading to Subversion plugin 2.4.x?
            Hide
            hmf Hans Marggraff added a comment -

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

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

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

            Show
            hmf Hans Marggraff added a comment - Daniel: I have tried it with three different Jenkins configurations all running on Linux servers against the same repository (Server version Subversion 1.6.11 (r934486)). It is managed by enterprise it, so I can not do anything about it. (Its a global Bank, so upgrading software is extremely conservative) However it works on a very old installation of Jenkins, so the server does not seem to be the problem: 1. Jenkins 1.549, Credentials plugin 1.9.4, Subversion Plugin 1.54, Subversion Workspace format 1.6 It fails after upgrading to newer versions of Jenkins: 2. Jenkins version 1594, Credentials Plugin 1.20, subversion plugin 2.5, Workspace format 1.6 3. Jenkins 1.596, Credentials Plugin 1.19, subversion plugin 2.4.5, Workspace format 1.7 To me it is the credentials plugin (or its use by the subversion plugin), that seems most suspicious. The upgrade made it a lot more complicated in a way, that we neither need nor want. Also Idea configured to use svnkit does not have any problems with the externals setup from my local windows development machine.
            Hide
            hmf Hans Marggraff added a comment -

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

            Show
            hmf Hans Marggraff added a comment - This is what our subversion configuration with credentials looks like. Maybe something is wrong there?
            hmf Hans Marggraff made changes -
            hmf Hans Marggraff made changes -
            Attachment Jenkins-externals .png [ 28343 ]
            Hide
            ermeaney Eric Meaney added a comment - - edited

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

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

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

            Show
            ermeaney Eric Meaney added a comment - - edited I am also having the same problem that Hans notes, and it seems mostly to revolve around the svn externals. We use a lot of them, and it really becomes an issue. I also had it working with an older version of Jenkins and plugins, I moved to a new server and this is coming up all the time. EDIT: After adding the alternate credentials to all my jobs,this is not happening anymore.
            Hide
            podskalsky podskalsky added a comment -

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

            Show
            podskalsky podskalsky added a comment - I have the same problem on my projects with svn:externals (sometimes)
            Hide
            chris_mh3 chris_mh3 added a comment - - edited

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

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

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

            Reverting back to Subversion 1.4.5 solved the problem.

            Show
            chris_mh3 chris_mh3 added a comment - - edited The Subversion plugin 2.5 completely broke polling for me. Just polling not checkout. Although there also have been new sporadic problems with externals on checkout. I am using variables in my URLs. The values are defined as Environment variables in the system configuration. org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. Subversion: 2.5 Jenkins: 1.580.2 Credentials: 1.21 Workspace: 1.8 and 1.7 Reverting back to Subversion 1.4.5 solved the problem.
            Hide
            alexlaw Alex Law added a comment -

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

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

            This occurs with and without Additional Credentials being set.

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

            hudson.util.IOException2: revision check failed on https://svn/path/here
            at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:196)
            at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:137)
            at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
            at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
            at hudson.scm.SCM.checkout(SCM.java:484)
            at hudson.model.AbstractProject.checkout(AbstractProject.java:1265)
            at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622)
            at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
            at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
            at hudson.model.Run.execute(Run.java:1759)
            at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
            at hudson.model.ResourceController.execute(ResourceController.java:89)
            at hudson.model.Executor.run(Executor.java:240)
            Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
            svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
            at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60)
            at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
            at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759)
            at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371)
            at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359)
            at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710)
            at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
            at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
            at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032)
            at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:175)
            at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
            at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:184)
            at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
            at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
            at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
            at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
            at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259)
            at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
            at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968)
            at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873)
            at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:184)
            ... 12 more
            Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
            at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:689)
            ... 30 more

            Show
            alexlaw Alex Law added a comment - As Hans and Eric have said, we're also receiving this on Externals during builds: intermittently and which external causes this can vary. We are attempting to switch to Jenkins now and use a lot of externals, so unable to define if working before. We've seen a job succeed and then the downstream project fail with this exception as well. Downstream may or may not succeed, if it fails it may or may not be due to the same external as the upstream. Very odd to see it work sometimes and not others. This occurs with and without Additional Credentials being set. Subversion: 2.5 Jenkins: 1.596 Credentials: 1.21 Workspace: 1.8 hudson.util.IOException2: revision check failed on https://svn/path/here at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:196) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:137) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860) at hudson.scm.SCM.checkout(SCM.java:484) at hudson.model.AbstractProject.checkout(AbstractProject.java:1265) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528) at hudson.model.Run.execute(Run.java:1759) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:175) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:184) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:184) ... 12 more Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:689) ... 30 more
            Hide
            tkrah Torsten Krah added a comment -

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

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

            Going back to 2.4.5 and it worked again.

            Show
            tkrah Torsten Krah added a comment - Same here with Subversion 2.5, Working Copy 1.7 and Jenkins 1.598. svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. Going back to 2.4.5 and it worked again.
            Hide
            donatello Stephan Grimm added a comment -

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

            Show
            donatello Stephan Grimm added a comment - We have the same problem. Sometimes it works, sometimes it fails. Does anybody know if there is any action here?
            Hide
            alexey_larsky Alexey Larsky added a comment -

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

            Show
            alexey_larsky Alexey Larsky added a comment - I have an issue only with lastest Subversion plugin 2.5 version. Previos 2.4.5 works stable. You can install it.
            Hide
            mabahj Markus added a comment -

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

            Show
            mabahj Markus added a comment - We're also seeing this problem after upgrading to 2.5. Had to downgrade to 2.4.5.
            Hide
            jamsw JAM Software added a comment - - edited

            We are having the same troubles here.

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

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

            After downgrading to subversion plugin 2.4.5 polling works as always.

            Show
            jamsw JAM Software added a comment - - edited We are having the same troubles here. E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. environment: Jenkins 1.598 running on Windows Server 2012 R2 Standard, 64 bit relevant plugins: Subversion 2.5; Credentials 1.22 After downgrading to subversion plugin 2.4.5 polling works as always.
            danielbeck Daniel Beck made changes -
            Link This issue is duplicated by JENKINS-27620 [ JENKINS-27620 ]
            Hide
            aristedes aristedes added a comment -

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

            Show
            aristedes aristedes added a comment - Does anyone have a workaround for this? About 20% of our builds fail because of this. Running the build again and everything works.
            Hide
            renea Rene Affourtit added a comment -

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

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

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

            Started by timer
            [Checkout log]
            At revision 6
            no change for [module2] since the previous build
            no change for [^\external1] since the previous build
            no change for [^\external2] since the previous build
            hudson.util.IOException2: revision check failed on [^\external3]
            at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:196)
            at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:137)
            at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
            at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
            at hudson.scm.SCM.checkout(SCM.java:485)
            at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
            at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
            at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
            at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
            at hudson.model.Run.execute(Run.java:1744)
            at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
            at hudson.model.ResourceController.execute(ResourceController.java:98)
            at hudson.model.Executor.run(Executor.java:374)
            Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
            svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
            at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60)
            at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
            at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759)
            at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371)
            at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359)
            at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710)
            at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
            at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
            at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032)
            at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:175)
            at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
            at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:184)
            at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
            at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
            at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
            at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
            at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259)
            at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
            at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968)
            at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873)
            at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:184)
            ... 12 more
            Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
            at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:689)
            ... 30 more

            Show
            renea Rene Affourtit added a comment - For me this is a random failure mode. Polling for Changes is succesfull about 90% of the builds. However: we have a few Timed jobs which do a complete clean checkout every night. The checkout succeeds, but the following building of the changelog fails. Jenkins 1.612 , subversion 2.5, credentials 1.22 svn server is accessed via https with username + password Started by timer [Checkout log] At revision 6 no change for [module2] since the previous build no change for [^\external1] since the previous build no change for [^\external2] since the previous build hudson.util.IOException2: revision check failed on [^\external3] at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:196) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:137) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1276) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) at hudson.model.Run.execute(Run.java:1744) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:374) Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:175) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:184) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:184) ... 12 more Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:689) ... 30 more
            Hide
            jp Jiri Pergl added a comment - - edited

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

            We have received this stacktrace:
            hudson.util.IOException2: revision check failed on http://externalUrl/project.Foo/trunk/xxx/
            at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:196)
            at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:137)
            at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
            at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
            at hudson.scm.SCM.checkout(SCM.java:484)
            at hudson.model.AbstractProject.checkout(AbstractProject.java:1270)
            at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
            at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
            at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
            at hudson.model.Run.execute(Run.java:1718)
            at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
            at hudson.model.ResourceController.execute(ResourceController.java:89)
            at hudson.model.Executor.run(Executor.java:240)
            Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
            svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
            at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60)
            at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
            at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759)
            at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371)
            at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359)
            at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710)
            at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
            at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
            at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032)
            at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:175)
            at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
            at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:184)
            at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
            at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
            at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
            at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
            at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259)
            at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
            at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968)
            at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873)
            at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:184)
            ... 12 more
            Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
            at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:689)

            Show
            jp Jiri Pergl added a comment - - edited Hi, we have a similar problem with the latest Subversion plugin 2.5 version. We have a project which has svn:external dependency. If we do a commit to this external and then executed the job, the svn update is failed. This problem is only for the first execution of the job after commit to the external, next repeating of the job is successful. We have received this stacktrace: hudson.util.IOException2: revision check failed on http://externalUrl/project.Foo/trunk/xxx/ at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:196) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:137) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860) at hudson.scm.SCM.checkout(SCM.java:484) at hudson.model.AbstractProject.checkout(AbstractProject.java:1270) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531) at hudson.model.Run.execute(Run.java:1718) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:175) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:184) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:184) ... 12 more Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:689)
            Hide
            alexey_larsky Alexey Larsky added a comment - - edited

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

            Show
            alexey_larsky Alexey Larsky added a comment - - edited Suppose it because only first time you really getting externals. After you will get them (and got error) if them was changed.
            Hide
            renea Rene Affourtit added a comment -

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

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

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

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

            Show
            renea Rene Affourtit added a comment - I've enabled logging for hudson.scm (level all): When I combine this with the build log (same machine, so no master/client time issues): (svnlog) 07:58:45: attempting auth for .../cobra/trunk [caused by polling svn] (build) 07:58:45: Building in WorkSpace ... (build) 07:58:46: Updating .../cobra/trunk (svnlog) 07:58:47: attempting auth for .../cobra/trunk [caused by svn update] (build) ... svn update (build) ... fetching externals (svnlog) 07:59:19: attempting auth for .../cobra/trunk [caused by building of changelog] (build) 07:59:20: No Change for <external1> since last build (svnlog) 07:59:20: attempting auth for <external2> [caused by building of changelog (?)] (build) 07:59:20: hudson.util.IOException2: revision check failed on <external2>{quote} <external2> is in the same repositiory as the project being built. The url for external2 has been configured in add extra credentials. the realm for cobra/trunk/ and external2 in the log file is both the same (and correct). Any suggestions on how to get (or add) extra logging to troubleshoot this issue?
            Hide
            alexanderfendt Alexander Fendt added a comment -

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

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

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

            Show
            renea Rene Affourtit added a comment - Rebuilt svn plugin with svnkit 1.8.10. No change. Created a test build which did a complete checkout every 10 minutes. Checkout always succeeds (114x), building the Changelog sometimes fails (1x of the 3 changes to this particular project).
            Hide
            jdege Jeff Dege added a comment -

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

            Show
            jdege Jeff Dege added a comment - Same - encountered the issue with 2.5, rolled back to 2.4.5 and it was gone. (Jenkins 1.612)
            Hide
            renea Rene Affourtit added a comment -

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

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

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

            When a user commits only to projecta all is well.

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

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

            Show
            renea Rene Affourtit added a comment - A scenario to reproduce: SVN repository hosted via https (assume https://localhost/svn/ ) SVN authentification via username/password. (other combinations have not been tested) In the Repository are two projects: projecta/trunk and projectb/trunk. projecta/trunk has an svn:externals property projb=^/projectb/trunk. Jenkins project points to https://localhost/svn/projecta/trunk . To exclude faults additional credentials have been added for https://localhost/svn/projectb/trunk . When a user commits only to projecta all is well. When a user commits to projectb, retrieving of the changelog fails. when polling is used to trigger, no build is started. When a timed build is used, the build fails because the change log can not be made. logging shows that in CredentialsSVNAuthenticationProviderImpl.requestClientAuthentication the 'List<SVNAuthentication> authentications' remains empty.
            Hide
            stephenconnolly Stephen Connolly added a comment -

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

            Show
            stephenconnolly Stephen Connolly added a comment - Rene Affourtit thank you for that test case. I will see if I can reproduce the issue from your description
            Hide
            perun Petr Vejchoda added a comment -

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

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

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

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

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

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

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

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

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

            Similarly if subversion is running via svnserve you might see

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

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

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

            Show
            stephenconnolly Stephen Connolly added a comment - Rene Affourtit So I was able to get the issue you describe by following your test case... but it would appear - at least from my testing - that the issue is really that the additional credentials have not been provided. As soon as I added additional credentials with the correct realm the polling started to work and the issue disappeared. The key thing to remember is that svn:externals can be used to leverage the read-access that Jenkins has against the repository where you might have lesser access. So if I have write access to projecta but no access to projectc, Jenkins may well be locked down so I can only see the projecta job, but by committing an svn:externals pointing at projectc and modifying the build script to tar-gz the contents of that external and sftp it to my computer I can effectively bypass the security permissions on the subversion repository. The hard part is getting the realm correct, so for example if you run: $ svn info https: //svn.apache.org/repos/ private Authentication realm: <https: //svn.apache.org:443> ASF Members ... Then the realm you want to specify in additional credentials is: < https://svn.apache.org:443 > ASF Members Similarly if subversion is running via svnserve you might see $ svn info svn: //localhost Authentication realm: <svn: //localhost:3690> cd90323c-3140-4208-9a36-a9a21ef8b680 And again the realm you need to specify in the additional credentials would be: <svn://localhost:3690> cd90323c-3140-4208-9a36-a9a21ef8b680 Can you check whether you actually have specified the realm correctly?
            Hide
            renea Rene Affourtit added a comment -

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

            Show
            renea Rene Affourtit added a comment - Stephen Connolly Okay, this works for me. I had specified the urls of the externals, not the realm.
            Hide
            stephenconnolly Stephen Connolly added a comment -

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

            Show
            stephenconnolly Stephen Connolly added a comment - From all the test cases presented so far, this is a case of the incorrect realm or no realm being configured.
            stephenconnolly Stephen Connolly made changes -
            Status Reopened [ 4 ] Resolved [ 5 ]
            Resolution Not A Defect [ 7 ]
            Hide
            danielbeck Daniel Beck added a comment -

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

            Show
            danielbeck Daniel Beck added a comment - JENKINS-21785 discussed the externals issue before in great detail. We should limit this one specifically to variables in the URL.
            Hide
            aristedes aristedes added a comment -

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

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

            which part is the realm that Jenkins is wanting?

            Show
            aristedes aristedes added a comment - How can you display the realm for a repository? For me with svn 1.8.13 on OSX I get this: $ svn info Path: . Working Copy Root Path: /Users/ari/svn/apache-foundation URL: https://svn.apache.org/repos/private/foundation Relative URL: ^/foundation Repository Root: https://svn.apache.org/repos/private Repository UUID: 694d45b4-53eb-0310-9336-ddcd440d954d Revision: 59701 Node Kind: directory Schedule: normal Last Changed Author: clr Last Changed Rev: 59700 Last Changed Date: 2015-06-25 10:54:00 +1000 (Thu, 25 Jun 2015) which part is the realm that Jenkins is wanting?
            Hide
            tkrah Torsten Krah added a comment - - edited

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

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

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

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

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

            Show
            tkrah Torsten Krah added a comment - Reopened to discuss the possible regression vs. 2.4 plugin version.
            tkrah Torsten Krah made changes -
            Resolution Not A Defect [ 7 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            tkrah Torsten Krah made changes -
            Labels credentials credentials regression
            Hide
            renea Rene Affourtit added a comment -

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

            Show
            renea Rene Affourtit added a comment - Created JENKINS-29079 to discuss possible improvements of the configuration.
            Hide
            recena Manuel Recena Soto added a comment -

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

            Show
            recena Manuel Recena Soto added a comment - T K Hello, Do you think that this ticket is related to JENKINS-23007 ? Maybe duplicated?
            Hide
            kasparek T K added a comment -

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

            Show
            kasparek T K added a comment - Yes, seems like the same problem with variables and repo URL
            Hide
            recena Manuel Recena Soto added a comment -

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

            Show
            recena Manuel Recena Soto added a comment - T K , Hello, Did you see that JENKINS-23007 was resolved recently?
            Hide
            splashnenen Alexandre Aubert added a comment -

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

            Show
            splashnenen Alexandre Aubert added a comment - Indeed, that should be ok for the case related to variables in url but does this fix also the case of repos with externals ?
            Hide
            recena Manuel Recena Soto added a comment -

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

            Show
            recena Manuel Recena Soto added a comment - Alexandre Aubert , Nothing releated with externals have been included in Subversion Plugin 2.5.2. But if you file an issue with a detailed description including a step by step process in order to reproduce the bug, I'd like to help you.
            Hide
            splashnenen Alexandre Aubert added a comment - - edited

            usecase is this one :

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

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

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

            (See attached 'external error' file)

            Show
            splashnenen Alexandre Aubert added a comment - - edited usecase is this one : main configured svn repository is : http://myrepo/example/main_product credentials for this repository are set using the 'credentials plugin' there are externals which are on the same repository (chechbox 'ignore externals' is obviously unchecked) The jobs polls the repo and update fails on external if those conditions are verified : 1. there are modifications on both main repository and this external 2. this external is referenced twice All externals passed ok, the one which is not up to date updates successfully then fails on second check with error "Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled." (See attached 'external error' file)
            splashnenen Alexandre Aubert made changes -
            Attachment external error.png [ 30506 ]
            Hide
            danielbeck Daniel Beck added a comment -

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

            Show
            danielbeck Daniel Beck added a comment - Alexandre Aubert Did you define Additional Credentials and make sure the authentication realm is the exact string used by your SVN server?
            Hide
            recena Manuel Recena Soto added a comment -

            Alexandre Aubert, I'll try to reproduce this scenario. Daniel Beck have pointed something important.

            Show
            recena Manuel Recena Soto added a comment - Alexandre Aubert , I'll try to reproduce this scenario. Daniel Beck have pointed something important.
            Hide
            splashnenen Alexandre Aubert added a comment -

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

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

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

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

            Show
            danielbeck Daniel Beck added a comment - I didn't define addintional credentials as the repository is the same than the main one in configuration. That's not how it works. See e.g. https://issues.jenkins-ci.org/browse/JENKINS-21785?focusedCommentId=196363&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-196363
            Hide
            splashnenen Alexandre Aubert added a comment - - edited

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

            Show
            splashnenen Alexandre Aubert added a comment - - edited Thanks for this information but it doesn't match with the fact that update is well done for external at first check, meaning that credentials are well used, no ? It's only at second check that it fails. Maybe we could check if Manuel is able to reproduce.
            Hide
            danielbeck Daniel Beck added a comment -

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

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

            Show
            danielbeck Daniel Beck added a comment - it doesn't match with the fact that update is well done for external at first check According to Stephen Connolly, the reason for this is connection reuse/caching of some kind in SVNKit.
            Hide
            kasparek T K added a comment - - edited

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

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

            String Parameter:
            name: REVISION
            default value: HEAD

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

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

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

            Bye

            Show
            kasparek T K added a comment - - edited Hello, checked the current behavior - the polling with variables seems to work as far as SVN is concerned now. The remaining problem is, that even if there is default value for the variable to be used for polling and build, the last manually used value (e.g. SVN branch for our case) is used instead of default value (trunk). e.g. This build is parameterized: name: SVN_SUBDIR repo url: svn+ssh://xxx/svn/PROJECT Default value: trunk String Parameter: name: REVISION default value: HEAD Source Code Management: repo url: svn+ssh://xxx/svn/PROJECT/${SVN_SUBDIR}@${REVISION} if I request the build of branch-ABC, then automatic polling will try to check this branch instead of trunk. Would you like me to fire this as new independent issue here? (not talking about SVN external for now) Bye
            Hide
            recena Manuel Recena Soto added a comment -

            T K Hello. In my opinion, the problem related to SCM Polling + parameterized URL is solved. It would be interesting to create another ticket to address your scenario. Do you agree?

            Show
            recena Manuel Recena Soto added a comment - T K Hello. In my opinion, the problem related to SCM Polling + parameterized URL is solved. It would be interesting to create another ticket to address your scenario. Do you agree?
            Hide
            splashnenen Alexandre Aubert added a comment -

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

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

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

            Show
            recena Manuel Recena Soto added a comment - alexandre aubert , I'll have to configure a similar scenario using externals.
            Hide
            alexey_larsky Alexey Larsky added a comment -

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

            Show
            alexey_larsky Alexey Larsky added a comment - The issue still present on plugin 2.5.2. Have to use 2.4.5.
            Hide
            tom_ghyselinck Tom Ghyselinck added a comment -

            Hi T K,

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

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

            Show
            tom_ghyselinck Tom Ghyselinck added a comment - Hi T K , Please check my proposal in JENKINS-19560 and related comments in JENKINS-14155 Both relate to handling the " DEFAULT " value and "automatic branch selection_.
            Hide
            tkrah Torsten Krah added a comment - - edited

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

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

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

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

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

            Updating https://svn.local.domain/svnrepos/dev/releases-hooks/trunk/usr-1.8 at revision '2015-09-16T13:05:00.748 +0200'
            Fetching 'https://svn.local.domain/svnrepos/dev/util/branches/1.8' at -1 into '/home/jenkins/Development/src/usr-1.8/util'
            U         util/src/java/de/sf/util/MailSender.java
            At revision 52046
            Fetching 'https://svn.local.domain/svnrepos/dev/usr/branches/1.8' at -1 into '/home/jenkins/Development/src/usr-1.8/usr'
            At revision 52046
            At revision 52046
            no change for https://svn.local.domain/svnrepos/dev/releases-hooks/trunk/usr-1.8 since the previous build
            hudson.util.IOException2: revision check failed on https://svn.local.domain/svnrepos/dev/util/branches/1.8
            	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:196)
            	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:137)
            	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:726)
            	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:861)
            	at hudson.scm.SCM.checkout(SCM.java:485)
            	at hudson.model.AbstractProject.checkout(AbstractProject.java:1277)
            	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
            	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
            	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
            	at hudson.model.Run.execute(Run.java:1741)
            	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
            	at hudson.model.ResourceController.execute(ResourceController.java:98)
            	at hudson.model.Executor.run(Executor.java:408)
            Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
            svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
            	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60)
            	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
            	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759)
            	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371)
            	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359)
            	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710)
            	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
            	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
            	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032)
            	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:175)
            	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
            	at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:184)
            	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
            	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
            	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
            	at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
            	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259)
            	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
            	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968)
            	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873)
            	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:184)
            	... 12 more
            Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
            	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:689)
            	... 30 more
            

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

            Show
            tkrah Torsten Krah added a comment - - edited I second alexandre aubert comment, this is still not fixed and still breaks for me with 2.5.3 - while 2.4.5 is working. Credentials are selected in the configuration and it does work while checking for updates on the checkout pointing to externals. But then looking for changes on those externals it fails - but both are in the same repository. Look at the trace below - it does successfully fetch changes from https://svn.local.domain/svnrepos/dev/util/branches/1.8 but fails later in the same run trying to look for changes on https://svn.local.domain/svnrepos/dev/util/branches/1.8 - how could this be, it can fetch data from there but is unable to check the revision later on - seems like a bug to me and reads like alexandre aubert problem. Updating https://svn.local.domain/svnrepos/dev/releases-hooks/trunk/usr-1.8 at revision '2015-09-16T13:05:00.748 +0200' Fetching 'https://svn.local.domain/svnrepos/dev/util/branches/1.8' at -1 into '/home/jenkins/Development/src/usr-1.8/util' U util/src/java/de/sf/util/MailSender.java At revision 52046 Fetching 'https://svn.local.domain/svnrepos/dev/usr/branches/1.8' at -1 into '/home/jenkins/Development/src/usr-1.8/usr' At revision 52046 At revision 52046 no change for https://svn.local.domain/svnrepos/dev/releases-hooks/trunk/usr-1.8 since the previous build hudson.util.IOException2: revision check failed on https://svn.local.domain/svnrepos/dev/util/branches/1.8 at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:196) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:137) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:726) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:861) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) at hudson.model.Run.execute(Run.java:1741) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:408) Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:175) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:184) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:184) ... 12 more Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled. at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:689) ... 30 more FYI: I don't use any variables in URLs, just externals are used.
            tkrah Torsten Krah made changes -
            Environment CentOS 6 64bit master, Win7 64bit, CentOS 5 64bit slaves.

            Jenkins ver. 1.558

            subversion plugin: 2.3-SNAPSHOT (private-04/07/2014 06:29-jenkins)
            credentials plugin: 1.10
            (other plugins via screenshot)
            CentOS 6 64bit master, Win7 64bit, CentOS 5 64bit slaves.

            Jenkins ver. 1.558
            Jenkins ver. 1.629

            subversion plugin: 2.3-SNAPSHOT (private-04/07/2014 06:29-jenkins), 2.5.3
            credentials plugin: 1.10, 1.23
            (other plugins via screenshot)
            recena Manuel Recena Soto made changes -
            Assignee stephenconnolly [ stephenconnolly ] Manuel Jesús Recena Soto [ recena ]
            Hide
            recena Manuel Recena Soto added a comment -

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

            Show
            recena Manuel Recena Soto added a comment - Torsten Krah Thanks so much. Your feedback is awesome. I can work on this bug with your information.
            Hide
            recena Manuel Recena Soto added a comment - - edited

            Torsten Krah

            Environment
            • Jenkins ver. 1.568 (minimum version required by Subversion Plugin)
            • Subversion Plugin 2.5.3
            • svnserve, version 1.6.17 (r1128011)
            • 1 repository with name: external1 (requires credentials)
            • 1 repository with name: JENKINS-22542 (requires the same credentials) and its svn:externals property:
              pegaso:JENKINS-22542 recena$ svn propget svn:externals
              svn://192.168.1.106/external1 external1
              
            First build (checkout process)
            Started by user anonymous
            [EnvInject] - Loading node environment variables.
            Building in workspace /Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542
            Checking out a fresh workspace because there's no workspace at /Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542
            Cleaning local Directory .
            Checking out svn://192.168.1.106/JENKINS-22542 at revision '2015-09-17T00:39:46.217 +0200'
             U        .
            Fetching 'svn://192.168.1.106/external1' at -1 into '/Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542/external1'
            A         external1/file1.txt
             U        external1
            At revision 3
            At revision 4
            no change for svn://192.168.1.106/JENKINS-22542 since the previous build
            no change for svn://192.168.1.106/external1 since the previous build
            Finished: SUCCESS
            
            Second build (update process)
            Started by user anonymous
            [EnvInject] - Loading node environment variables.
            Building in workspace /Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542
            Updating svn://192.168.1.106/JENKINS-22542 at revision '2015-09-17T00:40:18.385 +0200'
            Fetching 'svn://192.168.1.106/external1' at -1 into '/Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542/external1'
            At revision 3
            At revision 4
            no change for svn://192.168.1.106/JENKINS-22542 since the previous build
            no change for svn://192.168.1.106/external1 since the previous build
            Finished: SUCCESS
            
            SCM Polling
            Started on Sep 17, 2015 1:05:00 AM
            Received SCM poll call on master for JENKINS-22542 on Sep 17, 2015 1:05:00 AM
            svn://192.168.1.106/JENKINS-22542 is at revision 4
            svn://192.168.1.106/external1 is at revision 3
            Done. Took 33 ms
            No changes
            

            In Jenkins, Subversion Workspace Version configured to 1.8

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

            Show
            recena Manuel Recena Soto added a comment - - edited Torsten Krah Environment Jenkins ver. 1.568 (minimum version required by Subversion Plugin) Subversion Plugin 2.5.3 svnserve, version 1.6.17 (r1128011) 1 repository with name: external1 (requires credentials) 1 repository with name: JENKINS-22542 (requires the same credentials) and its svn:externals property: pegaso:JENKINS-22542 recena$ svn propget svn:externals svn://192.168.1.106/external1 external1 First build (checkout process) Started by user anonymous [EnvInject] - Loading node environment variables. Building in workspace /Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542 Checking out a fresh workspace because there's no workspace at /Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542 Cleaning local Directory . Checking out svn://192.168.1.106/JENKINS-22542 at revision '2015-09-17T00:39:46.217 +0200' U . Fetching 'svn://192.168.1.106/external1' at -1 into '/Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542/external1' A external1/file1.txt U external1 At revision 3 At revision 4 no change for svn://192.168.1.106/JENKINS-22542 since the previous build no change for svn://192.168.1.106/external1 since the previous build Finished: SUCCESS Second build (update process) Started by user anonymous [EnvInject] - Loading node environment variables. Building in workspace /Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542 Updating svn://192.168.1.106/JENKINS-22542 at revision '2015-09-17T00:40:18.385 +0200' Fetching 'svn://192.168.1.106/external1' at -1 into '/Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542/external1' At revision 3 At revision 4 no change for svn://192.168.1.106/JENKINS-22542 since the previous build no change for svn://192.168.1.106/external1 since the previous build Finished: SUCCESS SCM Polling Started on Sep 17, 2015 1:05:00 AM Received SCM poll call on master for JENKINS-22542 on Sep 17, 2015 1:05:00 AM svn://192.168.1.106/JENKINS-22542 is at revision 4 svn://192.168.1.106/external1 is at revision 3 Done. Took 33 ms No changes In Jenkins, Subversion Workspace Version configured to 1.8 I could not reproduce the bug. I'll try with more configurations. Any idea is welcome.
            Hide
            renea Rene Affourtit added a comment -

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

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

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

            Show
            renea Rene Affourtit added a comment - Torsten Krah Are you sure the realm is specified correctly? See also https://issues.jenkins-ci.org/browse/JENKINS-22542?focusedCommentId=230849 by stephen connolly. The Realm is NOT h..ps://svn.local.domain/svnrepos/dev/util , but should look more like "<h..ps://svn.local.comain> svn users" . When you create a new set of credentials the realm is used as the description.
            Hide
            splashnenen Alexandre Aubert added a comment -

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

            • use 'credentials plugin' and set credentials as user/password in the credentials global configuration
            • configure your job to use this credential
            • make changes in your 'external1' so that the build will update this external
            • run this build and you should have the problem which happens during last phase of summary displaying 'No change for...'
              Please let me know if you need any further information.
            Show
            splashnenen Alexandre Aubert added a comment - Hi Manuel Recena Soto . Thanks for these tests. To me, your case is correct. To reproduce now, you may try a third run : use 'credentials plugin' and set credentials as user/password in the credentials global configuration configure your job to use this credential make changes in your 'external1' so that the build will update this external run this build and you should have the problem which happens during last phase of summary displaying 'No change for...' Please let me know if you need any further information.
            Hide
            tkrah Torsten Krah added a comment - - edited

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

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

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

            Show
            tkrah Torsten Krah added a comment - - edited Rene Affourtit You are speaking about the Realm i can specify when using Additional Credentials. However i did not even considered to configure additional ones because i don't need them. The external points to the same repository, i am just using global credentials and configured to job to use them. I can't specify a Realm in the global credentials - i've just configured there my URI spec to be https, the hostname to be svn.local.domain and the path part to be /svnrepos/** . Looking at the help of Description part when creating new credentials it reads: A description for the domain, not used by Jenkins itself. So something wrong there if i need to add a Realm to a description field which is not used.
            Hide
            recena Manuel Recena Soto added a comment -

            Hi alexandre aubert,

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

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

            Show
            recena Manuel Recena Soto added a comment - Hi alexandre aubert , I used credentials-plugin to set my credentials. I configured my job to use this credentials. I'm going to try your third and fourth step.
            Hide
            tkrah Torsten Krah added a comment - - edited

            Manuel Recena Soto

            I got it instantly failing with this recipe:

            1. create a new svn repository /tmp/JENKINS-22542 with svnadmin create and configure svnserve.conf, use default passwd stuff.
            2. start it svnserve -d --foreground -r /tmp/JENKINS-22542
            3. go to /tmp/import directory and create 3 dirs there: root, link1, link2
            4. do a svn import for for those 3
            5. go to /tmp/checkout and do a svn checkout svn://localhost:3690/
            6. now create a file in link1 directory which contains:
              link2 svn://localhost:3690/link2
              link1 svn://localhost:3690/link1
              
            1. now cd to root directory and do a svn propset svn:externals --file ../link1/test .
            2. do a svn ci . on root
            1. Now configure a freestyle build job which uses current credentials plugin and subversion plugin and point configuration to:
              svn://localhost:3690/root
            1. Add global credentials there for harry/harryssecret using the passwd stuff from svnserve. Run it - works.
            2. Now do a "svn add test" in the link1 directory and commit it.
            3. Now trigger a second build - it fetches the changed file but fails on calcChangeLog(..)
            4. Run it again - works now again.
            5. Edit the "test" file and switch lines and commit the change.
            6. Trigger the build again - failing again.
            Show
            tkrah Torsten Krah added a comment - - edited Manuel Recena Soto I got it instantly failing with this recipe: create a new svn repository /tmp/ JENKINS-22542 with svnadmin create and configure svnserve.conf, use default passwd stuff. start it svnserve -d --foreground -r /tmp/ JENKINS-22542 go to /tmp/import directory and create 3 dirs there: root, link1, link2 do a svn import for for those 3 go to /tmp/checkout and do a svn checkout svn://localhost:3690/ now create a file in link1 directory which contains: link2 svn://localhost:3690/link2 link1 svn://localhost:3690/link1 now cd to root directory and do a svn propset svn:externals --file ../link1/test . do a svn ci . on root Now configure a freestyle build job which uses current credentials plugin and subversion plugin and point configuration to: svn://localhost:3690/root Add global credentials there for harry/harryssecret using the passwd stuff from svnserve. Run it - works. Now do a "svn add test" in the link1 directory and commit it. Now trigger a second build - it fetches the changed file but fails on calcChangeLog(..) Run it again - works now again. Edit the "test" file and switch lines and commit the change. Trigger the build again - failing again.
            Hide
            renea Rene Affourtit added a comment -

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

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

            Show
            renea Rene Affourtit added a comment - Torsten Krah I was under the same assumption. But as of 2.5.0 there is a regression (in my eyes) that whenever you use externals you need to specify additional (but the same) credentials. These credentials are only used for changelog calculations. Can you try with additional credentials specified? And yes, the description field for credentials is not used by jenkins. But the value which is automatically filled in there when you create the credentials matches the realm name.
            Hide
            tkrah Torsten Krah added a comment -

            Rene Affourtit

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

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

            Rene Affourtit, Torsten Krah

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

            Show
            recena Manuel Recena Soto added a comment - Rene Affourtit , Torsten Krah I agree, it is illogical (and an UX issue). I'll solve it this night.
            Hide
            renea Rene Affourtit added a comment -

            Manuel Recena Soto to save you some time searching:

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

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

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

            Show
            renea Rene Affourtit added a comment - Manuel Recena Soto to save you some time searching: I looked earlier this year but haven't had the time to really dive in, fix and test. I came to the conclusion that the fault is likely in SubversionChangeLoguilder.Java:128 ISVNAuthenticationProvider authProvider = CredentialsSVNAuthenticationProviderImpl .createAuthenticationProvider(build.getParent(), scm, null ); The null should (I think) be the module location, but I'm not sure how situation with different modules including externals are to be handled.
            Hide
            danielbeck Daniel Beck added a comment -

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

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

            It works without that in 2.4.5.

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

            Show
            danielbeck Daniel Beck added a comment - However i did not even considered to configure additional ones because i don't need them. The external points to the same repository, i am just using global credentials and configured to job to use them. You'll get nowhere by refusing to do what everyone tells you is the solution to this issue. That additional credentials are needed has been posted in numerous comments to this issue for over a year. I realize that having to do this is a bit annoying (been there, reconfigured 400 jobs), but for now the solution for externals and variables is to use Additional Credentials. It works without that in 2.4.5. I think It was always supposed to fail as a security measure as Stephen Connolly explained in a comment above. He once told me that there's an issue with SVNKit reusing the same connection to download externals when it should not. Since 2.5 updated SVNKit to a new version, it's likely some part of that behavior was changed there.
            Hide
            tkrah Torsten Krah added a comment - - edited

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

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

            Show
            tkrah Torsten Krah added a comment - - edited I don't refuse anything - i just try to understand why this is failing now and if there is some good reason - at least the changelog for subversion should mark a breaking change here so that users know about. Imho its just not logical - its called Additional - not "External Credentials" - why can't Jenkins just provide the same configured gobal credentials automatically in that case? Another thing which is confusing - if this is a security measure - its imho failing, because it does fetch the external changes but does only fail on Changelog generation - if its for security, it should fail already fetching the external stuff but it fails only for changelog stuff - why is this difference, i would expect to fail completly and not to be able to fetch the external stuff and failing later on the not so important changelog (in case of security terms)? I am just trying to understand why this should be the "official" solution to that problem - it seems not logical and at least until now i did not read something why Jenkins can't provide a better solution to that case than doubling all credentials configuration. Another Idea - if this is the proposed solution - why keeping the first credentials option at all? Just remove it and rename "Additional Credentials" to "Credentials" and users are forced to set some Credentials there. They won't do it twice and i would work out-of-the box, how about that?
            Hide
            danielbeck Daniel Beck added a comment -

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

            Please let me repeat:

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

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

            Show
            danielbeck Daniel Beck added a comment - Another thing which is confusing - if this is a security measure - its imho failing Please let me repeat: … there's an issue with SVNKit reusing the same connection to download externals when it should not. Since 2.5 updated SVNKit to a new version, it's likely some part of that behavior was changed there. I'm not 100% sure this is the cause here, but it looks like a possible culprit.
            Hide
            tkrah Torsten Krah added a comment -

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

            Show
            tkrah Torsten Krah added a comment - If there is an issue there - can you link the upstream bugreport from SVNKit in this ticket please?
            Hide
            recena Manuel Recena Soto added a comment -

            Torsten Krah

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

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

            Show
            recena Manuel Recena Soto added a comment - Torsten Krah I did more tests with this environment and everything is working fine . I'm going to try with your environment, svn:externals against the same repository.
            Hide
            recena Manuel Recena Soto added a comment -

            hallelujah! It seems I found the bug!

            Show
            recena Manuel Recena Soto added a comment - hallelujah! It seems I found the bug!
            Hide
            gaborv Gabor V added a comment -

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

            Show
            gaborv Gabor V added a comment - @Manuel: We are eager to hear the story + when the fix will come out...
            Hide
            bangalore Bengt Fahlgren added a comment -

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

            Show
            bangalore Bengt Fahlgren added a comment - @ Manuel Eagerly awaiting your fix. Since we use LTS releases, we ask for a new LTS bugfix release asap.
            Hide
            recena Manuel Recena Soto added a comment -

            Bengt Fahlgren AFAIK, LTS policy only applies to Jenkins CORE.

            Show
            recena Manuel Recena Soto added a comment - Bengt Fahlgren AFAIK, LTS policy only applies to Jenkins CORE.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

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

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

            Show
            oleg_nenashev Oleg Nenashev added a comment - Yes, SVN plugin is independent from Jenkins core since 1.4xx (I don't recall the exact version). You can just update the plugin when it gets released. The new version will be bundled into Jenkins core in 1.625.2, I suppose
            Hide
            danielbeck Daniel Beck added a comment -

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

            Show
            danielbeck Daniel Beck added a comment - Oleg Nenashev SVN plugin has been detached from core since 1.310. And we're still bundling 1.54 due to the change to credential storage in Subversion 2.0.
            Hide
            recena Manuel Recena Soto added a comment -

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

            Show
            recena Manuel Recena Soto added a comment - Daniel Beck but, Would it be possible to update Subversion Plugin in the next LTS?
            Hide
            danielbeck Daniel Beck added a comment -

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

            Show
            danielbeck Daniel Beck added a comment - You can update any plugin to any version compatible with the release you're running. For Subversion plugin, this is 1.568 and newer.
            Hide
            recena Manuel Recena Soto added a comment -

            Daniel Beck, I meant here (bundled).

            Show
            recena Manuel Recena Soto added a comment - Daniel Beck , I meant here (bundled).
            Hide
            danielbeck Daniel Beck added a comment -

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

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

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

            Show
            hjen Jennifer Hofmeister added a comment - Manuel Recena Soto , if you have a minute, please tell us what the bug was! There seem to be a number of people, including me, waiting eagerly to know what was the cause of our troubles
            Hide
            recena Manuel Recena Soto added a comment - - edited

            Hi,

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

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

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

            Regards,

            Show
            recena Manuel Recena Soto added a comment - - edited Hi, I said I had found the bug but if you configure the additional credentials in a right way, everything works fine. In my case, I configured a credentials (in additional credentials) using this realm <svn://192.168.1.106:3690> example real . It is very important that the realm is written rightly. Here you can see two console outputs (SCM Polling): Started on Sep 22, 2015 10:24:00 PM Received SCM poll call on master for JENKINS-22542 on Sep 22, 2015 10:24:00 PM svn://192.168.1.106/JENKINS-22542 is at revision 7 svn://192.168.1.106/external1 is at revision 4 svn://192.168.1.106/external2 is at revision 1 Done. Took 0.18 sec No changes Started on Sep 22, 2015 10:26:00 PM Received SCM poll call on master for JENKINS-22542 on Sep 22, 2015 10:26:00 PM svn://192.168.1.106/JENKINS-22542 is at revision 8 (changed from 7) svn://192.168.1.106/external1 is at revision 4 svn://192.168.1.106/external2 is at revision 1 Done. Took 24 ms Changes found Regards,
            recena Manuel Recena Soto made changes -
            Link This issue is related to JENKINS-21785 [ JENKINS-21785 ]
            Hide
            pschoemig Philip Schömig added a comment -

            Hi,

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

            <https://svn/repo> Subversion Repository

            didn't seem to work.

            Regards,
            Philip

            Show
            pschoemig Philip Schömig added a comment - Hi, can you please tell me how to configure the additional credentials when the Subversion server is using a HTTPS connection because <https://svn/repo> Subversion Repository didn't seem to work. Regards, Philip
            Hide
            tkrah Torsten Krah added a comment -

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

            Show
            tkrah Torsten Krah added a comment - Manuel Recena Soto - so just for understanding - is this default behaviour going to be fixed to use the configured default credentials when searching for additional credentials and nothing extra is configured to get this one working - or whats the proposed solution in an UX friendly way?
            Hide
            danielbeck Daniel Beck added a comment -
            Show
            danielbeck Daniel Beck added a comment - Philip Schömig Please read JENKINS-21785 .
            Hide
            recena Manuel Recena Soto added a comment -

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

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

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

            Regards,

            Show
            recena Manuel Recena Soto added a comment - Philip Schömig , you have to use realm. It is a string. To know this value, I followed these basic steps: Remove my .subversion folder (in my local development environment) Checkout the source code. This was the output pegaso:temp recena$ svn co https: //subversion.assembla.com/svn/jenkins-26318/ Error validating server certificate for 'https: //subversion.assembla.com:443' : - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: *.assembla.com - Valid: from Wed, 16 Apr 2014 13:31:17 GMT until Thu, 24 Mar 2016 19:30:40 GMT - Issuer: http: //certs.godaddy.com/repository/, GoDaddy.com, Inc., Scottsdale, Arizona, US - Fingerprint: ec:9f:9d:b2:39:e1:34:81:7b:27:f6:51:30:8b:ac:41:5b:62:09:19 (R)eject, accept (t)emporarily or accept (p)ermanently? p Authentication realm: <https: //subversion.assembla.com:443> Assembla Restricted Area Password for 'recena' : You can see my realm: < https://subversion.assembla.com:443 > Assembla Restricted Area Regards,
            Hide
            recena Manuel Recena Soto added a comment -

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

            Show
            recena Manuel Recena Soto added a comment - Torsten Krah , the main goal here is to verify that there is no bug. If we want to improve this, we should file a new ticket for that.
            Hide
            tkrah Torsten Krah added a comment - - edited

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

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

            Torsten Krah, Manuel Recena Soto , there is already a ticket: JENKINS-29079 .

            Show
            renea Rene Affourtit added a comment - Torsten Krah , Manuel Recena Soto , there is already a ticket: JENKINS-29079 .
            Hide
            recena Manuel Recena Soto added a comment -

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

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

            If T K agree, I propose to close this ticket.

            Show
            recena Manuel Recena Soto added a comment - Torsten Krah , I think it is more interesting if we close this ticket and continue working on JENKINS-29079 . In this ticket there is enough information to clarify this UX issue. If T K agree, I propose to close this ticket.
            recena Manuel Recena Soto made changes -
            Status Reopened [ 4 ] Resolved [ 5 ]
            Resolution Not A Defect [ 7 ]
            tkrah Torsten Krah made changes -
            Link This issue is related to JENKINS-29079 [ JENKINS-29079 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 154644 ] JNJira + In-Review [ 194977 ]

              People

              • Assignee:
                recena Manuel Recena Soto
                Reporter:
                kasparek T K
              • Votes:
                39 Vote for this issue
                Watchers:
                55 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: