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.

    • Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Blocker Blocker
    • subversion-plugin

      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

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

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

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

          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,

          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,

          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

          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

          Torsten Krah added a comment -

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

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

          Daniel Beck added a comment -

          pschoemig Please read JENKINS-21785.

          Daniel Beck added a comment - pschoemig Please read JENKINS-21785 .

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

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

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

          Regards,

          Manuel Recena Soto added a comment - pschoemig , 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,

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

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

          Torsten Krah added a comment - - edited

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

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

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

          Rene Affourtit added a comment - tkrah , recena , there is already a ticket: JENKINS-29079 .

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

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

          If kasparek agree, I propose to close this ticket.

          Manuel Recena Soto added a comment - tkrah , I think it is more interesting if we close this ticket and continue working on JENKINS-29079 . In this ticket there is enough information to clarify this UX issue. If kasparek agree, I propose to close this ticket.

            recena Manuel Recena Soto
            kasparek T K
            Votes:
            39 Vote for this issue
            Watchers:
            54 Start watching this issue

              Created:
              Updated:
              Resolved: