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

Check for changes in folders linked via svn:externals fails due to missing credentials

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • subversion-plugin
    • None
    • Windows 7 x64 for both hosts and slaves, Linux for both hosts and slaves

      Note from the commenters:

      This bug has been resolved in Subversion Plugin 2.3. You just need to reconfigure your jobs. You have to add all SVN Credentials as "Additional Credentials" in the job config with correct realm notation "<proto://server:port> SvnRealmName". Please read the comments below.

      • Find out the SVN realm name on your client like this:
        svn --no-auth-cache --config-dir invalid info proto://host:port/path/to/repo
      • The SVN realm name is set in your SVN Server config svnserve.conf (realm = realm-name). See man pages here.
      • If you are using svn+ssh your realm will be in the "svn+ssh://server-name" format. No port, no pointy brackets, no extra realm name.
      • Add "Additional Credentials" for *all* repositories involved at the checkout - also for repositories which are referenced by SVN externals.

      Original Bug Description:

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

      hudson.util.IOException2: revision check failed on https://svn.dummyserver.org/svn/Data/trunk/Dummy
      	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:189)
      	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
      	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:736)
      	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897)
      	at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:651)
      	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:560)
      	at hudson.model.Run.execute(Run.java:1670)
      	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      	at hudson.model.ResourceController.execute(ResourceController.java:88)
      	at hudson.model.Executor.run(Executor.java:231)
      Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/Data/trunk/Dummy failed
      	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384)
      	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
      	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
      	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
      	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
      	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
      	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020)
      	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180)
      	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
      	at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)
      	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
      	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
      	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
      	at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
      	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
      	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
      	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967)
      	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
      	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:177)
      	... 11 more
      Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
      	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
      	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
      	at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185)
      	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:694)
      	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
      	... 29 more
      

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

          @WH sadly svnkit does not give you that ability. The only thing it lets you have access to is the realm

          Stephen Connolly added a comment - @WH sadly svnkit does not give you that ability. The only thing it lets you have access to is the realm

          Daniel Beck added a comment -

          wh

          Why not implementing this solution? It would solve the orginal error of this issue.

          I'm sure a pull request by anyone wishing to provide this would be appreciated by many.


          stephenconnolly How does that work given that regular checkout simply reuses the same credential for checking out any externals? If the job configurer provides a sufficiently powerful credential, then any externals will also be checked out. It's only when an external cannot be checked out using the configured credential that it falls back to Additional Credentials.

          Therefore I consider it a viable solution to annotate any external location in the project with the module location that introduced it to reuse its credential – at least that's not brute-forcing credentials like in 1.x.

          Daniel Beck added a comment - wh Why not implementing this solution? It would solve the orginal error of this issue. I'm sure a pull request by anyone wishing to provide this would be appreciated by many. stephenconnolly How does that work given that regular checkout simply reuses the same credential for checking out any externals? If the job configurer provides a sufficiently powerful credential, then any externals will also be checked out. It's only when an external cannot be checked out using the configured credential that it falls back to Additional Credentials. Therefore I consider it a viable solution to annotate any external location in the project with the module location that introduced it to reuse its credential – at least that's not brute-forcing credentials like in 1.x.

          @Daniel Beck

          Ha! it only seems that way. What happens is that SVNKit caches the realms/connections it has used already and reuses the existing connection from the connection pool. So it is the SVNKit library pulling the security rug out from under us

          Stephen Connolly added a comment - @Daniel Beck Ha! it only seems that way. What happens is that SVNKit caches the realms/connections it has used already and reuses the existing connection from the connection pool. So it is the SVNKit library pulling the security rug out from under us

          Daniel Beck added a comment -

          A valid enhancement request would be to give a checkbox (default to off) to use matching module credentials when doing a checkout of externals. That would at least make things easier for the 80% who don't need the gaping security hole fixed because of their permissive SVN server security model.

          Not sure how that would work. In checkout, it's already effectively this way, and for polling etc. you have no idea which module introduced which external (AFAIK – is there a field I am missing?).


          Alternative approach:

          The current implementation allows to leave the per-module credentials empty and only specify Additional Credentials (just ignore the scary form validation errors) which are then used for all locations.

          We could go one step further and add a 'Default Credentials' field (or reinterpret an Additional Credential with empty realm?). Leave that field empty/don't define such an Additional Credential, and you get the current behavior. Select a credential as Default Credential/define such an Additional Credential and you can skip configuring any others.

          This way, users conscious about the security issue prevented by the credentials implementation can continue to specify individual credentials and curse SVNKit for its behavior while the rest can configure one credential, and don't have to care about externals or realms.

          WDYT?

          Daniel Beck added a comment - A valid enhancement request would be to give a checkbox (default to off) to use matching module credentials when doing a checkout of externals. That would at least make things easier for the 80% who don't need the gaping security hole fixed because of their permissive SVN server security model. Not sure how that would work. In checkout, it's already effectively this way, and for polling etc. you have no idea which module introduced which external (AFAIK – is there a field I am missing?). Alternative approach: The current implementation allows to leave the per-module credentials empty and only specify Additional Credentials (just ignore the scary form validation errors) which are then used for all locations. We could go one step further and add a 'Default Credentials' field (or reinterpret an Additional Credential with empty realm?). Leave that field empty/don't define such an Additional Credential, and you get the current behavior. Select a credential as Default Credential/define such an Additional Credential and you can skip configuring any others. This way, users conscious about the security issue prevented by the credentials implementation can continue to specify individual credentials and curse SVNKit for its behavior while the rest can configure one credential, and don't have to care about externals or realms. WDYT?

          danielbeck: alternative approach sounds good. I would go for a explicit "Default credentials" field instead of implicit behaviour when leaving realm empty.

          Christoph Vogtländer added a comment - danielbeck : alternative approach sounds good. I would go for a explicit "Default credentials" field instead of implicit behaviour when leaving realm empty.

          ben s added a comment -

          We just ran into this issue. Glad to see there's already a solution, but it's really not ideal, having to walk through dozens of jobs and adding the same "Additional Credentials" field. It feels extremely redundant given it's all the same realm/credentials as each project's modules, and it looks sorta ugly (which is a nitpick, I guess).

          Forgive me as it's tough to determine from the above conversation - has it been decided that a "global" setting for this will be added at some point in a future version of the plugin? Is that what JENKINS-17103 is now addressing?

          Thanks

          ben s added a comment - We just ran into this issue. Glad to see there's already a solution, but it's really not ideal, having to walk through dozens of jobs and adding the same "Additional Credentials" field. It feels extremely redundant given it's all the same realm/credentials as each project's modules, and it looks sorta ugly (which is a nitpick, I guess). Forgive me as it's tough to determine from the above conversation - has it been decided that a "global" setting for this will be added at some point in a future version of the plugin? Is that what JENKINS-17103 is now addressing? Thanks

          Daniel Beck added a comment - - edited

          The following would be a rough outline of a script to run in Script Console that adds an Additional Credential (by copying the first location's credential) to all projects with known externals:

          Jenkins.instance.getAllItems(AbstractProject).each { p ->
            if (p.scm instanceof hudson.scm.SubversionSCM) {
              if (p.scm.locations.size() < p.scm.getProjectLocations(p).size()) {
                // known externals
                println p.fullDisplayName
                if (p.scm.locations.size() == 0) {
                  println "... no configured locations!?"
                  return
                }
                def auth = p.scm.locations[0].@credentialsId
                if (auth == null) {
                  println "... no auth for first location"
                  return
                }
                if (p.scm.@additionalCredentials == null) {
                	p.scm.@additionalCredentials = []
                }
                p.scm.@additionalCredentials.add(new hudson.scm.SubversionSCM.AdditionalCredentials('<https://svnserver:443> Subversion Authentication', auth))
                println "... adding additional credential"
                p.save()
              }
            }
          }
          return

          Just replace the domain "<https://svnserver:443> Subversion Authentication" with whatever's correct for you. It's a bit rough around the edges (e.g. doesn't check whether there's already an Additional Credential for the specified realm, only reuses the first location's credential ID, doesn't check whether the credential domain matches the auth realm, ...), but it should be a start.

          Daniel Beck added a comment - - edited The following would be a rough outline of a script to run in Script Console that adds an Additional Credential (by copying the first location's credential) to all projects with known externals: Jenkins.instance.getAllItems(AbstractProject).each { p -> if (p.scm instanceof hudson.scm.SubversionSCM) { if (p.scm.locations.size() < p.scm.getProjectLocations(p).size()) { // known externals println p.fullDisplayName if (p.scm.locations.size() == 0) { println "... no configured locations!?" return } def auth = p.scm.locations[0].@credentialsId if (auth == null ) { println "... no auth for first location" return } if (p.scm.@additionalCredentials == null ) { p.scm.@additionalCredentials = [] } p.scm.@additionalCredentials.add( new hudson.scm.SubversionSCM.AdditionalCredentials( '<https: //svnserver:443> Subversion Authentication' , auth)) println "... adding additional credential" p.save() } } } return Just replace the domain "< https://svnserver:443 > Subversion Authentication" with whatever's correct for you. It's a bit rough around the edges (e.g. doesn't check whether there's already an Additional Credential for the specified realm, only reuses the first location's credential ID, doesn't check whether the credential domain matches the auth realm, ...), but it should be a start.

          ben s added a comment -

          Fantastic. Your script did the trick with only a few small changes (to suit our specific needs) and saved me time and groaning.

          ben s added a comment - Fantastic. Your script did the trick with only a few small changes (to suit our specific needs) and saved me time and groaning.

          I spent the morning brute forcing adding an external credential to over 300 jobs, if this helps anyone, enjoy:

          find . -name config.xml -exec sed -i '|</locations>| a <additionalCredentials>\n<hudson.scm.SubversionSCM_-AdditionalCredentials>\n<realm>http://YOURSUBVERSIONSERVER</realm>\n<credentialsId></credentialsId>\n</hudson.scm.SubversionSCM_-AdditionalCredentials>\n</additionalCredentials>' {} \;

          Jason Potkanski added a comment - I spent the morning brute forcing adding an external credential to over 300 jobs, if this helps anyone, enjoy: find . -name config.xml -exec sed -i '|</locations>| a <additionalCredentials>\n<hudson.scm.SubversionSCM_-AdditionalCredentials>\n<realm> http://YOURSUBVERSIONSERVER </realm>\n<credentialsId></credentialsId>\n</hudson.scm.SubversionSCM_-AdditionalCredentials>\n</additionalCredentials>' {} \;

          I'm using externals. Few of them point to one host others to a different host. For each host I have separated creditation. Unfortunately mentioned workaround doesn't work for me, I still have an error:

          hudson.util.IOException2: revision check failed on https://host2/svn/repo/trunk
          	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:191)
          	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
          

          My job config.xml looks like that:

            <scm class="hudson.scm.SubversionSCM" plugin="subversion@2.4">
              <locations>
                <hudson.scm.SubversionSCM_-ModuleLocation>
                  <remote>https://hostname1/svn/repo/trunk</remote>
                  <credentialsId>xxx</credentialsId>
                  <local>.</local>
                  <depthOption>infinity</depthOption>
                  <ignoreExternalsOption>false</ignoreExternalsOption>
                </hudson.scm.SubversionSCM_-ModuleLocation>
              </locations>
              <additionalCredentials>
                <hudson.scm.SubversionSCM_-AdditionalCredentials>
                  <realm>&lt;https://hostname2:443&gt; Authorization Realm</realm>
                  <credentialsId>yyy</credentialsId>
                </hudson.scm.SubversionSCM_-AdditionalCredentials>
                <hudson.scm.SubversionSCM_-AdditionalCredentials>
                  <realm>&lt;https://hostname1:443&gt; Authorization Realm</realm>
                  <credentialsId>xxx</credentialsId>
                </hudson.scm.SubversionSCM_-AdditionalCredentials>
              </additionalCredentials>
          ...
          

          Is it something wrong with my configuration?

          Pawel Grzegrzolka added a comment - I'm using externals. Few of them point to one host others to a different host. For each host I have separated creditation. Unfortunately mentioned workaround doesn't work for me, I still have an error: hudson.util.IOException2: revision check failed on https://host2/svn/repo/trunk at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:191) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132) My job config.xml looks like that: <scm class="hudson.scm.SubversionSCM" plugin="subversion@2.4"> <locations> <hudson.scm.SubversionSCM_-ModuleLocation> <remote>https://hostname1/svn/repo/trunk</remote> <credentialsId>xxx</credentialsId> <local>.</local> <depthOption>infinity</depthOption> <ignoreExternalsOption>false</ignoreExternalsOption> </hudson.scm.SubversionSCM_-ModuleLocation> </locations> <additionalCredentials> <hudson.scm.SubversionSCM_-AdditionalCredentials> <realm>&lt;https://hostname2:443&gt; Authorization Realm</realm> <credentialsId>yyy</credentialsId> </hudson.scm.SubversionSCM_-AdditionalCredentials> <hudson.scm.SubversionSCM_-AdditionalCredentials> <realm>&lt;https://hostname1:443&gt; Authorization Realm</realm> <credentialsId>xxx</credentialsId> </hudson.scm.SubversionSCM_-AdditionalCredentials> </additionalCredentials> ... Is it something wrong with my configuration?

          Daniel Beck added a comment -

          pawelgrz: Please post the full stack trace. The relevant parts seem to be missing.

          Daniel Beck added a comment - pawelgrz : Please post the full stack trace. The relevant parts seem to be missing.

          Pawel Grzegrzolka added a comment - - edited

          Here you go:

          hudson.util.IOException2: revision check failed on https://host/svn/repo/trunk
          	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:191)
          	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
          	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:735)
          	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:873)
          	at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
          	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
          	at hudson.model.Run.execute(Run.java:1684)
          	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          	at hudson.model.ResourceController.execute(ResourceController.java:88)
          	at hudson.model.Executor.run(Executor.java:231)
          Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/repo/trunk failed
          	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384)
          	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
          	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
          	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
          	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
          	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
          	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020)
          	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180)
          	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
          	at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)
          	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
          	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
          	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
          	at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
          	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
          	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
          	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967)
          	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
          	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:179)
          	... 11 more
          Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
          	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
          	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
          	at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185)
          	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:694)
          	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
          	... 29 more
          

          Pawel Grzegrzolka added a comment - - edited Here you go: hudson.util.IOException2: revision check failed on https://host/svn/repo/trunk at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:191) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:735) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:873) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580) at hudson.model.Run.execute(Run.java:1684) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/repo/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:179) ... 11 more Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32) at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:694) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 29 more

          Jim . added a comment - - edited

          EDIT:
          Ooops. Found the reason:
          As soon as repo address and realm have both IP or both hostname (not when one has the name and another has IP) - it works OK. Sorry for reopening. My bad.


          Still happens every time some module is changed. Despite additional credentials with proper realm are set and "Emulate clean checkout ..." is choosen...
          If I manually remove all contents of job directory on the node (including .svn dir) - this node checkouts and builds absolutely OK, without this error. Until next time the module is changed - then this error appears again, and nothing helps, even setting "Check-out Strategy" to "Always check out a fresh copy". And I'm forced to manually run the ugly hack - groovy-script which totally cleans all job-directories on all nodes again (about 35 jobs on 5 different OS servers - Windows, Linux and OSX)...

          Jenkins version 1.574, svn plugin 2.4.1


          no change for svn://10.0.0.10/volumes/VOL_1/svnhome/repo/Thirdparty/trunk/boost/bin since the previous build
          no change for svn://10.0.0.10/volumes/VOL_1/svnhome/repo/Thirdparty/trunk/curl/bin since the previous build
          no change for svn://10.0.0.10/volumes/VOL_1/svnhome/repo/Thirdparty/trunk/freeimage/bin since the previous build
          no change for svn://10.0.0.10/volumes/VOL_1/svnhome/repo/Thirdparty/trunk/freetype/bin since the previous build
          no change for svn://10.0.0.10/volumes/VOL_1/svnhome/repo/Thirdparty/trunk/glew/bin since the previous build
          hudson.util.IOException2: revision check failed on svn://10.0.0.10/volumes/VOL_1/svnhome/repo/Thirdparty/trunk/juce/src/modules
          	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:191)
          	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
          	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:735)
          	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:873)
          	at hudson.model.AbstractProject.checkout(AbstractProject.java:1254)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:624)
          	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:530)
          	at hudson.model.Run.execute(Run.java:1740)
          	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          	at hudson.model.ResourceController.execute(ResourceController.java:88)
          	at hudson.model.Executor.run(Executor.java:234)
          Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
          	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
          	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
          	at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185)
          	at org.tmatesoft.svn.core.internal.io.svn.sasl.SVNSaslAuthenticator.createSaslClient(SVNSaslAuthenticator.java:306)
          	at org.tmatesoft.svn.core.internal.io.svn.sasl.SVNSaslAuthenticator.authenticate(SVNSaslAuthenticator.java:92)
          	at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.authenticate(SVNConnection.java:194)
          	at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.authenticate(SVNRepositoryImpl.java:1275)
          	at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1253)
          	at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLatestRevision(SVNRepositoryImpl.java:168)
          	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
          	at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)
          	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
          	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
          	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
          	at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
          	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
          	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
          	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967)
          	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
          	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:179)
          	... 11 more

          Jim . added a comment - - edited EDIT: Ooops. Found the reason: As soon as repo address and realm have both IP or both hostname (not when one has the name and another has IP) - it works OK. Sorry for reopening. My bad. Still happens every time some module is changed. Despite additional credentials with proper realm are set and " Emulate clean checkout ... " is choosen... If I manually remove all contents of job directory on the node (including .svn dir) - this node checkouts and builds absolutely OK, without this error. Until next time the module is changed - then this error appears again, and nothing helps, even setting " Check-out Strategy " to " Always check out a fresh copy ". And I'm forced to manually run the ugly hack - groovy-script which totally cleans all job-directories on all nodes again (about 35 jobs on 5 different OS servers - Windows, Linux and OSX)... Jenkins version 1.574 , svn plugin 2.4.1 no change for svn://10.0.0.10/volumes/VOL_1/svnhome/repo/Thirdparty/trunk/boost/bin since the previous build no change for svn://10.0.0.10/volumes/VOL_1/svnhome/repo/Thirdparty/trunk/curl/bin since the previous build no change for svn://10.0.0.10/volumes/VOL_1/svnhome/repo/Thirdparty/trunk/freeimage/bin since the previous build no change for svn://10.0.0.10/volumes/VOL_1/svnhome/repo/Thirdparty/trunk/freetype/bin since the previous build no change for svn://10.0.0.10/volumes/VOL_1/svnhome/repo/Thirdparty/trunk/glew/bin since the previous build hudson.util.IOException2: revision check failed on svn://10.0.0.10/volumes/VOL_1/svnhome/repo/Thirdparty/trunk/juce/src/modules at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:191) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:735) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:873) at hudson.model.AbstractProject.checkout(AbstractProject.java:1254) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:624) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:530) at hudson.model.Run.execute(Run.java:1740) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:234) Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32) at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185) at org.tmatesoft.svn.core.internal.io.svn.sasl.SVNSaslAuthenticator.createSaslClient(SVNSaslAuthenticator.java:306) at org.tmatesoft.svn.core.internal.io.svn.sasl.SVNSaslAuthenticator.authenticate(SVNSaslAuthenticator.java:92) at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.authenticate(SVNConnection.java:194) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.authenticate(SVNRepositoryImpl.java:1275) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1253) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLatestRevision(SVNRepositoryImpl.java:168) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:179) ... 11 more

          Jim . added a comment -

          As soon as repo address and realm have both IP or both hostname (not when one has the name and another has IP) - it works OK.

          Jim . added a comment - As soon as repo address and realm have both IP or both hostname (not when one has the name and another has IP) - it works OK.

          Andreas Katzig added a comment - - edited

          We still encounter this issue, although I read through all comments and have configured everything accordingly and correct (in my opinion).

          We use Jenkins ver. 1.565.1 with Subversion plugin 2.4.1. We're using externals, build servers nodes, I added additional credentials for them, took care of the correct naming with its correct realm and brackets.

          Every random build does fail with the following exception, and this issue is really getting very very frustrating because the next build is working fine then. The Subversion plugin should be updated to improve the user experience (and functionality).

          no change for svn://xxx:3688/user/yyy/aaa since the previous build
          hudson.util.IOException2: revision check failed on svn://xxx:3688/zzz/code/trunk
          	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:191)
          	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
          	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:735)
          	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:873)
          	at hudson.model.AbstractProject.checkout(AbstractProject.java:1252)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:615)
          	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:524)
          	at hudson.model.Run.execute(Run.java:1706)
          	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          	at hudson.model.ResourceController.execute(ResourceController.java:88)
          	at hudson.model.Executor.run(Executor.java:232)
          Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
          	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
          	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
          	at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185)
          	at org.tmatesoft.svn.core.internal.io.svn.sasl.SVNSaslAuthenticator.createSaslClient(SVNSaslAuthenticator.java:306)
          	at org.tmatesoft.svn.core.internal.io.svn.sasl.SVNSaslAuthenticator.authenticate(SVNSaslAuthenticator.java:92)
          	at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.authenticate(SVNConnection.java:194)
          	at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.authenticate(SVNRepositoryImpl.java:1275)
          	at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1253)
          	at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLatestRevision(SVNRepositoryImpl.java:168)
          	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
          	at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)
          	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
          	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
          	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
          	at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
          	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
          	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
          	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967)
          	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
          	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:179)
          	... 11 more
          Finished: FAILURE
          

          Andreas Katzig added a comment - - edited We still encounter this issue, although I read through all comments and have configured everything accordingly and correct (in my opinion). We use Jenkins ver. 1.565.1 with Subversion plugin 2.4.1. We're using externals, build servers nodes, I added additional credentials for them, took care of the correct naming with its correct realm and brackets. Every random build does fail with the following exception, and this issue is really getting very very frustrating because the next build is working fine then. The Subversion plugin should be updated to improve the user experience (and functionality). no change for svn: //xxx:3688/user/yyy/aaa since the previous build hudson.util.IOException2: revision check failed on svn: //xxx:3688/zzz/code/trunk at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:191) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:735) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:873) at hudson.model.AbstractProject.checkout(AbstractProject.java:1252) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:615) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:524) at hudson.model.Run.execute(Run.java:1706) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:232) Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try . Authentication failed at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32) at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185) at org.tmatesoft.svn.core.internal.io.svn.sasl.SVNSaslAuthenticator.createSaslClient(SVNSaslAuthenticator.java:306) at org.tmatesoft.svn.core.internal.io.svn.sasl.SVNSaslAuthenticator.authenticate(SVNSaslAuthenticator.java:92) at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.authenticate(SVNConnection.java:194) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.authenticate(SVNRepositoryImpl.java:1275) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1253) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLatestRevision(SVNRepositoryImpl.java:168) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:179) ... 11 more Finished: FAILURE

          Daniel Beck added a comment -

          Andreas: Try the following: Create a new log recorder at Manage Jenkins » System Log and add the logger hudson.scm.CredentialsSVNAuthenticationProviderImpl at level FINE. Retry. Check the log output. Anything interesting?

          Daniel Beck added a comment - Andreas: Try the following: Create a new log recorder at Manage Jenkins » System Log and add the logger hudson.scm.CredentialsSVNAuthenticationProviderImpl at level FINE . Retry. Check the log output. Anything interesting?

          Andreas Katzig added a comment - - edited

          Thanks for getting back Daniel.

          I did what you recommended, but the log doesn't tell me anything interesting:

          Aug 19, 2014 2:05:19 PM FINE hudson.scm.CredentialsSVNAuthenticationProviderImpl requestClientAuthentication
          Attempting auth for URL: svn://svnserver:3688/user/xxx/__USER; Realm: <svn://svnserver:3688> REALMNAME
          
          Aug 19, 2014 2:05:19 PM FINE hudson.scm.CredentialsSVNAuthenticationProviderImpl requestClientAuthentication
          Attempting auth for URL: svn://svnserver:3688/user/xxx/__USER; Realm: <svn://svnserver:3688> REALMNAME
          
          Aug 19, 2014 2:05:20 PM FINE hudson.scm.CredentialsSVNAuthenticationProviderImpl requestClientAuthentication
          Attempting auth for URL: svn://svnserver:3698/Library/branches/yyy-0.1/Tools/Tool1; Realm: <svn://svnserver:3698> REALMNAME
          
          Aug 19, 2014 2:05:21 PM FINE hudson.scm.CredentialsSVNAuthenticationProviderImpl requestClientAuthentication
          Attempting auth for URL: svn://svnserver:3688/xxx/code/trunk; Realm: <svn://svnserver:3688> REALMNAME
          

          The build to which the log above belongs failed again.
          I figured out that the build always fails the first time some changes are checked in to SVN (still funny that the next checkout/build will succeed).

          To explain our SVN infrastructure a bit:

          • We use initial checkout paths which contain only svn:externals, which are pointing to different source paths and also different repositories (as you can see with the port number).
          • The error "hudson.util.IOException2: revision check failed on ..."always happens on the first external - in case of the above log it's "svn://xxx:3688/zzz/code/trunk".
          • The external property pointing to the same repo is defined like this: "^/zzz/code/trunk localpath"
          • External properties pointing to different repositories are defined like this: "svn://svnserver:3698/remotepath localpath"

          Screenshot from the SVN settings within the build job:

          What I saw in the SCM logs was that some repositories are trying to connect to the SVN server via IP, which would not work when the realm is defined with the hostname.
          This doesn't affect the current build I'm talking about though, or at least not in a way I'm able to comprehend.

          Unfortunately the SCM log does not show which build job was triggering SVN activity - I'll try to set the log level to "finer", maybe I'll find something that helps.

          I will also try to replace the circumflex "^" in the external definition with the absolute hostname. Will give feedback if that helped, but I would hate to change that for our 20+ repositories with 5 externals checkout paths each (would > 100 changes)

          After checking the next build, which succeeds, I'm also sure that SVN is not trying to connect to the server via IP instead of the hostname.

          Any more clues?

          Andreas Katzig added a comment - - edited Thanks for getting back Daniel. I did what you recommended, but the log doesn't tell me anything interesting: Aug 19, 2014 2:05:19 PM FINE hudson.scm.CredentialsSVNAuthenticationProviderImpl requestClientAuthentication Attempting auth for URL: svn: //svnserver:3688/user/xxx/__USER; Realm: <svn://svnserver:3688> REALMNAME Aug 19, 2014 2:05:19 PM FINE hudson.scm.CredentialsSVNAuthenticationProviderImpl requestClientAuthentication Attempting auth for URL: svn: //svnserver:3688/user/xxx/__USER; Realm: <svn://svnserver:3688> REALMNAME Aug 19, 2014 2:05:20 PM FINE hudson.scm.CredentialsSVNAuthenticationProviderImpl requestClientAuthentication Attempting auth for URL: svn: //svnserver:3698/Library/branches/yyy-0.1/Tools/Tool1; Realm: <svn://svnserver:3698> REALMNAME Aug 19, 2014 2:05:21 PM FINE hudson.scm.CredentialsSVNAuthenticationProviderImpl requestClientAuthentication Attempting auth for URL: svn: //svnserver:3688/xxx/code/trunk; Realm: <svn://svnserver:3688> REALMNAME The build to which the log above belongs failed again. I figured out that the build always fails the first time some changes are checked in to SVN (still funny that the next checkout/build will succeed). To explain our SVN infrastructure a bit: We use initial checkout paths which contain only svn:externals, which are pointing to different source paths and also different repositories (as you can see with the port number). The error "hudson.util.IOException2: revision check failed on ..."always happens on the first external - in case of the above log it's "svn://xxx:3688/zzz/code/trunk". The external property pointing to the same repo is defined like this: "^/zzz/code/trunk localpath" External properties pointing to different repositories are defined like this: "svn://svnserver:3698/remotepath localpath" Screenshot from the SVN settings within the build job: What I saw in the SCM logs was that some repositories are trying to connect to the SVN server via IP, which would not work when the realm is defined with the hostname. This doesn't affect the current build I'm talking about though, or at least not in a way I'm able to comprehend. Unfortunately the SCM log does not show which build job was triggering SVN activity - I'll try to set the log level to "finer", maybe I'll find something that helps. I will also try to replace the circumflex "^" in the external definition with the absolute hostname. Will give feedback if that helped, but I would hate to change that for our 20+ repositories with 5 externals checkout paths each (would > 100 changes) After checking the next build, which succeeds, I'm also sure that SVN is not trying to connect to the server via IP instead of the hostname. Any more clues?

          if this is your screenshot then you have a typo in the port:
          3688 <-> 3698

          try with the same port and see if that solves your problem

          michael soukup added a comment - if this is your screenshot then you have a typo in the port: 3688 <-> 3698 try with the same port and see if that solves your problem

          It's not a typo, it's a different repository. Repo on port #3688 is the main repositories with externals pointing to the repo on port #3698.

          Andreas Katzig added a comment - It's not a typo, it's a different repository. Repo on port #3688 is the main repositories with externals pointing to the repo on port #3698.

          michael soukup added a comment - - edited

          yes - understood, but you have no additional credits for the 3688 port defined.
          I thought that you would have to add additional credentials for both ports / repositories.

          michael soukup added a comment - - edited yes - understood, but you have no additional credits for the 3688 port defined. I thought that you would have to add additional credentials for both ports / repositories.

          Yes, didn't add them because I thought it would be enough to have them defined above (As this is also the place were an error message is displayed if credentials are invalid or missing).

          So I'd have to define the main repositorie's credentials twice? What the actual #$+

          Will try and give feedback.

          We should really put some conclusion in big letters below this thread about what one have to pay attention to until the plugin's functionality is improved. It's already too many trial+error comments which may mislead the readers in here.

          Andreas Katzig added a comment - Yes, didn't add them because I thought it would be enough to have them defined above (As this is also the place were an error message is displayed if credentials are invalid or missing). So I'd have to define the main repositorie's credentials twice? What the actual #$+ Will try and give feedback. We should really put some conclusion in big letters below this thread about what one have to pay attention to until the plugin's functionality is improved. It's already too many trial+error comments which may mislead the readers in here.

          Daniel Beck added a comment -

          We should really put some conclusion in big letters below this thread about what one have to pay attention to until the plugin's functionality is improved. It's already too many trial+error comments which may mislead the readers in here.

          Tried that for a few issues, people kept on posting comments and those that came after didn't bother reading everything. So doesn't work. Edit the issue description again.

          But seriously, there's no magic going on. It's a straightforward key lookup. If it looks for a string that you don't supply exactly, it won't work.

          Daniel Beck added a comment - We should really put some conclusion in big letters below this thread about what one have to pay attention to until the plugin's functionality is improved. It's already too many trial+error comments which may mislead the readers in here. Tried that for a few issues, people kept on posting comments and those that came after didn't bother reading everything. So doesn't work. Edit the issue description again. But seriously, there's no magic going on. It's a straightforward key lookup. If it looks for a string that you don't supply exactly, it won't work.

          @Andreas, I agree it is a bit of a pain... any suggestions as to how to not permit drive-by credential scraping and at the same time make this easier to use are welcome.

          FYI the drive-by credential scraping is not theoretical, I know of at least one incident (of which I cannot say more)

          Stephen Connolly added a comment - @Andreas, I agree it is a bit of a pain... any suggestions as to how to not permit drive-by credential scraping and at the same time make this easier to use are welcome. FYI the drive-by credential scraping is not theoretical, I know of at least one incident (of which I cannot say more)

          @Daniel I read your note, but (at least to me) it wasn't clear enough as it didn't cover that we have to put ALL credentials in as "additional credentials". I'm still asking myself why the non-additional credentials field exists at all

          @Stephen I'm not aware of the drive-by credential scraping issue, but I'm honestly happy that you and others are taking care of it to increase security.

          I'm sure you guys are able to come up with some kicking UX update for the plugin to reduce the pain

          Andreas Katzig added a comment - @Daniel I read your note, but (at least to me) it wasn't clear enough as it didn't cover that we have to put ALL credentials in as "additional credentials". I'm still asking myself why the non-additional credentials field exists at all @Stephen I'm not aware of the drive-by credential scraping issue, but I'm honestly happy that you and others are taking care of it to increase security. I'm sure you guys are able to come up with some kicking UX update for the plugin to reduce the pain

          Bart M added a comment -

          I also seem to have the same problem, but my SVN externals are all on the same SVN server, accessible with the same credentials.

          It's strange though, when the CI build triggered by the change fails, and you just force it to build again, it works fine. It only seems to happen the first time svn had to update something (in the main checked out repo, not in one of the externals), if nothing changed in the checked out repository, everything continues as expected. If something updated - it fails with the "hudson.util.IOException2: revision check failed on http://svnserver/path/to/external" exception.

          We also use the '^' everywhere in our externals btw...

          I'm running Jenkins ver. 1.575 with SVN plugin ver. 2.4.3.

          Bart M added a comment - I also seem to have the same problem, but my SVN externals are all on the same SVN server, accessible with the same credentials. It's strange though, when the CI build triggered by the change fails, and you just force it to build again, it works fine. It only seems to happen the first time svn had to update something (in the main checked out repo, not in one of the externals), if nothing changed in the checked out repository, everything continues as expected. If something updated - it fails with the "hudson.util.IOException2: revision check failed on http://svnserver/path/to/external " exception. We also use the '^' everywhere in our externals btw... I'm running Jenkins ver. 1.575 with SVN plugin ver. 2.4.3.

          Chris Tobey added a comment -

          @stephenconnolly Is the option of adding a checkbox to "Use these credentials for all externals" out of the question?

          Chris Tobey added a comment - @stephenconnolly Is the option of adding a checkbox to "Use these credentials for all externals" out of the question?

          Shane Gannon added a comment - - edited

          I'm hitting this issue even though it is marked as resolved. Or potentially another problem with the same symptoms.

          The Subversion Plugin on our Jenkins is version 2.4.3 and "installed" 2.3. We have all our jobs configured with additional credentials like so

          Repository URL: https://mysvn.com/trunk@$SVN_REVISION
          Credentials: MyCreds

          Additional Credentials

          Realm: https://mysvn.com
          Credentials: MyCreds

          The problem occurs every time one of our svn externals change. e.g.

          Old SVN External: ^/sibling_of_trunk/path/to/code@191319 nativeapp
          New SVN External: ^/sibling_of_trunk/path/to/code@191325 nativeapp

          The next build will be fine.

          But these symptoms have been reported above. Yet the problem persists for me. What did I miss?

          PS: Apologies if I'm asking a question that's been posted. The thread above is difficult to follow.

          Shane Gannon added a comment - - edited I'm hitting this issue even though it is marked as resolved. Or potentially another problem with the same symptoms. The Subversion Plugin on our Jenkins is version 2.4.3 and "installed" 2.3. We have all our jobs configured with additional credentials like so Repository URL: https://mysvn.com/trunk@$SVN_REVISION Credentials: MyCreds Additional Credentials Realm: https://mysvn.com Credentials: MyCreds The problem occurs every time one of our svn externals change. e.g. Old SVN External: ^/sibling_of_trunk/path/to/code@191319 nativeapp New SVN External: ^/sibling_of_trunk/path/to/code@191325 nativeapp The next build will be fine. But these symptoms have been reported above. Yet the problem persists for me. What did I miss? PS: Apologies if I'm asking a question that's been posted. The thread above is difficult to follow.

          Daniel Beck added a comment -

          Shane: Seems to be unrelated AFAICT. Could you file a new issue?

          Daniel Beck added a comment - Shane: Seems to be unrelated AFAICT. Could you file a new issue?

          Shane Gannon added a comment -

          Can do Daniel - sorry about the confusion

          Shane Gannon added a comment - Can do Daniel - sorry about the confusion

          becky yy added a comment -

          Daniel,

          Recently we used VisualSVN Server to set up the repositories. And the credentials method is Integrated Windows Authentication. So it's controlled by Active Directory.
          In the jenkins project configuration, I entered my login id as the credentials. And also for the "Additional Credential", I have put "<https://svnserver:443> VisualSVN Server" and also used the same credentials as the repositories.

          However there are always an error "Unable to access https://library.mea.adinternal.com/svn/YYTest : svn: E200015:". I am not sure what's wrong. Do you have any idea?

          Thank you.

          becky yy added a comment - Daniel, Recently we used VisualSVN Server to set up the repositories. And the credentials method is Integrated Windows Authentication. So it's controlled by Active Directory. In the jenkins project configuration, I entered my login id as the credentials. And also for the "Additional Credential", I have put "< https://svnserver:443 > VisualSVN Server" and also used the same credentials as the repositories. However there are always an error "Unable to access https://library.mea.adinternal.com/svn/YYTest : svn: E200015:". I am not sure what's wrong. Do you have any idea? Thank you.

          Daniel Beck added a comment -

          becky12yy: Please don't ask for assistance in JIRA. It's irrelevant to the 60 people watching this. Use e.g. the jenkinsci-users mailing list for that instead.

          Daniel Beck added a comment - becky12yy : Please don't ask for assistance in JIRA. It's irrelevant to the 60 people watching this. Use e.g. the jenkinsci-users mailing list for that instead.

          If you use svn+ssh://SERVER/REPOSITORY_LOCATION for your external then use

          svn+ssh://SERVER

          as realm

          Patrick Savelberg added a comment - If you use svn+ssh://SERVER/REPOSITORY_LOCATION for your external then use svn+ssh://SERVER as realm

          Borzh Borzhovich added a comment - - edited

          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.
          

          Borzh Borzhovich added a comment - - edited 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.

          Nick Brown added a comment - - edited

          Updated to latest of everything yesterday (Jenkins 1.616 and SVN 2.5), added additional credentials and now have polling without errors. However I have a strange side effect when using relative external paths and polling a branch.

          I have a job that works fine on trunk including with externals but when I replicate that job and tweak the URLs to a branch the external polling still reports it is comparing the revisions from trunk even though the externals are defined with relative paths '../../../etc.' When the job runs it of course does the correct thing getting the relative externals from the branch but the polling log shows it is looking at them in trunk. Any ideas?

          Also I still can't use 'Prepare an environment for the run' to define 'Properties Content' variables that can then be used in the module URLs for polling. They do work fine when the job runs but polling fails and results in the job triggered every cycle. Last time I tried, if I use job parameters rather than variables defined as I mentioned they do work...

          Nick Brown added a comment - - edited Updated to latest of everything yesterday (Jenkins 1.616 and SVN 2.5), added additional credentials and now have polling without errors. However I have a strange side effect when using relative external paths and polling a branch. I have a job that works fine on trunk including with externals but when I replicate that job and tweak the URLs to a branch the external polling still reports it is comparing the revisions from trunk even though the externals are defined with relative paths '../../../etc.' When the job runs it of course does the correct thing getting the relative externals from the branch but the polling log shows it is looking at them in trunk. Any ideas? Also I still can't use 'Prepare an environment for the run' to define 'Properties Content' variables that can then be used in the module URLs for polling. They do work fine when the job runs but polling fails and results in the job triggered every cycle. Last time I tried, if I use job parameters rather than variables defined as I mentioned they do work...

          demonick, if you are using EnvInject Plugin + Subversion Plugin and you have problems with polling, please take a look to this issue JENKINS-29340.

          Manuel Recena Soto added a comment - demonick , if you are using EnvInject Plugin + Subversion Plugin and you have problems with polling, please take a look to this issue JENKINS-29340 .

          dan russell added a comment - - edited

          Seems a pretty clunky fix to have to put credentials in for each job that requires externals, shouldn't the plugin at least try the given credentials before failing?

          Also does anybody know why this is only an intermittent failure?

          dan russell added a comment - - edited Seems a pretty clunky fix to have to put credentials in for each job that requires externals, shouldn't the plugin at least try the given credentials before failing? Also does anybody know why this is only an intermittent failure?

          dan_smartstream

          If you have ideas to improve this, it would be helpful if you send an email (dev mailing list) with your proposal.

          Manuel Recena Soto added a comment - dan_smartstream If you have ideas to improve this, it would be helpful if you send an email (dev mailing list) with your proposal.

          Nick Brown added a comment - - edited

          Manuel, I apologise, my realm string had an error and it is in fact working fine with additional credentials.

          Nick Brown added a comment - - edited Manuel, I apologise, my realm string had an error and it is in fact working fine with additional credentials.

          demonick, thanks so much for your feedback. Definitely, this issue is solved.

          Manuel Recena Soto added a comment - demonick , thanks so much for your feedback. Definitely, this issue is solved.

          john little added a comment -

          in 15 years of using SVN, I have never had to use the realm, nor even known it existed. We have not found a way to get this yet. We are using assembla.com, and have raised a ticket with them to ask them to check their svnserve.conf files, as obviously we dont have access to this. It would a lot of someone could include some real exmaples of what these realms can be, and the entire string which must be pasted into the "Realm" box of the "additional credentials".

          john little added a comment - in 15 years of using SVN, I have never had to use the realm, nor even known it existed. We have not found a way to get this yet. We are using assembla.com, and have raised a ticket with them to ask them to check their svnserve.conf files, as obviously we dont have access to this. It would a lot of someone could include some real exmaples of what these realms can be, and the entire string which must be pasted into the "Realm" box of the "additional credentials".

          Daniel Beck added a comment -

          We have not found a way to get this yet.

          nutmix What about the dozens and dozens of comments on this issue explaining exactly this? Or the actual issue description that contains one possible way to determine the realm name directly below the giant red test?

          Daniel Beck added a comment - We have not found a way to get this yet. nutmix What about the dozens and dozens of comments on this issue explaining exactly this? Or the actual issue description that contains one possible way to determine the realm name directly below the giant red test?

          danielbeck, I've decided don't add more comment here. There is enough information about this.

          Manuel Recena Soto added a comment - danielbeck , I've decided don't add more comment here. There is enough information about this.

          john little added a comment -

          For us, svn --no-auth-cache --config-dir invalid info proto://host:port/path/to/repo does not return any realm info. It returns:

          Path: ourproject
          URL: https://subversion.assembla.com/svn/ourrepo
          Relative URL: ^/
          Repository Root: https://subversion.assembla.com/svn/ourrepo
          Repository UUID: 26850efa-2baa-4381-9140-fb0xxxxxxxxx
          Revision: 1755
          Node Kind: directory
          Last Changed Author: me
          Last Changed Rev: 1755
          Last Changed Date: 2015-12-10 15:23:10 +0100 (Thu, 10 Dec 2015)

          john little added a comment - For us, svn --no-auth-cache --config-dir invalid info proto://host:port/path/to/repo does not return any realm info. It returns: Path: ourproject URL: https://subversion.assembla.com/svn/ourrepo Relative URL: ^/ Repository Root: https://subversion.assembla.com/svn/ourrepo Repository UUID: 26850efa-2baa-4381-9140-fb0xxxxxxxxx Revision: 1755 Node Kind: directory Last Changed Author: me Last Changed Rev: 1755 Last Changed Date: 2015-12-10 15:23:10 +0100 (Thu, 10 Dec 2015)

          john little added a comment -

          I just realized that jira "hid" 155 comments. I just read them all. we were seeing the following:

          <https://subversion.assembla.com:443> Assembla Restricted

          Several times, but assumed that the realm could not possible be " Assembla Restricted" as it has spaces in it. We have tried the following under realms:

          "<https://subversion.assembla.com:443> Assembla Restricted"

          "<https://subversion.assembla.com:443>"

          "Assembla Restricted"

          and "https://subversion.assembla.com:443"

          Not knowing which of these is the right way to go.

          john little added a comment - I just realized that jira "hid" 155 comments. I just read them all. we were seeing the following: < https://subversion.assembla.com:443 > Assembla Restricted Several times, but assumed that the realm could not possible be " Assembla Restricted" as it has spaces in it. We have tried the following under realms: "< https://subversion.assembla.com:443 > Assembla Restricted" "< https://subversion.assembla.com:443 >" "Assembla Restricted" and "https://subversion.assembla.com:443" Not knowing which of these is the right way to go.

          @all: if you encounter this issue, before commenting

          • check that you followed the steps in the issue description at the top of this page
          • start reading at least comment-196458 to find out how your realm string should look like
          • if this does not work keep on reading the comments (including the linked comments)
          • if all this still does not get your installation working --> file a new issue with your stacktrace included

          hope this helps and the links make finding what you are looking for easier.

          michael soukup added a comment - @all: if you encounter this issue, before commenting check that you followed the steps in the issue description at the top of this page start reading at least comment-196458 to find out how your realm string should look like if this does not work keep on reading the comments (including the linked comments) if all this still does not get your installation working --> file a new issue with your stacktrace included hope this helps and the links make finding what you are looking for easier.

          "Reposiroty URL" : https://212.227.XXX.YYY:8443/svn/A/trunk/B
          Credentials : "user/***"
          In "Additional Credentials Realm ", I set : <https://212.227.XXX.YYY:8443> VisualSVN Server
          In "Additional Credentials Credentials" , I set "user/***"

          Still not work.

          Fabien Carmagnac added a comment - "Reposiroty URL" : https://212.227.XXX.YYY:8443/svn/A/trunk/B Credentials : "user/***" In "Additional Credentials Realm ", I set : < https://212.227.XXX.YYY:8443 > VisualSVN Server In "Additional Credentials Credentials" , I set "user/***" Still not work.

          ps :
          Jenkins ver. 1.647
          svn plugin : 2.5.7

          Fabien Carmagnac added a comment - ps : Jenkins ver. 1.647 svn plugin : 2.5.7

          We can find the realm using curl -I <url_external>

          curl will prompt:
          HTTP/1.1 401 Authorization Required
          Date: <current_date>
          Server: Apache/2.2.15 (CentOS)
          WWW-Authenticate: Basic realm=<SVN_REALM>
          Content-Type: text/html; charset=iso-8859-1

          I added the <SVN_REALM> realm value of WWW-Authenticate: Basic realm in the field Additional Credentials/Realm. That do not solve the problem, still have the job failed when it exists change in one of the externals. All externals are on the same SVN project.

          Bruno Pettorelli added a comment - We can find the realm using curl -I <url_external> curl will prompt: HTTP/1.1 401 Authorization Required Date: <current_date> Server: Apache/2.2.15 (CentOS) WWW-Authenticate: Basic realm=<SVN_REALM> Content-Type: text/html; charset=iso-8859-1 I added the <SVN_REALM> realm value of WWW-Authenticate: Basic realm in the field Additional Credentials/Realm. That do not solve the problem, still have the job failed when it exists change in one of the externals. All externals are on the same SVN project.

          bpetto35, Could you send the config.xml of your job?

          Manuel Recena Soto added a comment - bpetto35 , Could you send the config.xml of your job?

          Bruno Pettorelli added a comment - Manuel, config files for 2 jobs among many failing jobs. https://drive.google.com/open?id=0B3ZI9767SO40cW1DV1BYOTA3RDBwV3hUcmd3WVZsa0d4TURZ https://drive.google.com/open?id=0B3ZI9767SO40VjlHdF9tUTB1VGlxQjJJZFh4TXNON2h4bS1B

          I just went through this whole thing on my install. None of the ways to find the realm worked for me as I'm using svn+ssh.

          Finally enabling the logs in Jenkins on FINE with hudson.scm.CredentialsSVNAuthenticationProviderImpl helped me find the string which was in the "svn+ssh://server-name" format. No port, no pointy brackets, no extra realm name.

          I would suggest we add the svn+ssh info to the howto above.

          That was painful learning experience.

          Channy Tremblay added a comment - I just went through this whole thing on my install. None of the ways to find the realm worked for me as I'm using svn+ssh. Finally enabling the logs in Jenkins on FINE with hudson.scm.CredentialsSVNAuthenticationProviderImpl helped me find the string which was in the "svn+ssh://server-name" format. No port, no pointy brackets, no extra realm name. I would suggest we add the svn+ssh info to the howto above. That was painful learning experience.

          Markus Franke added a comment -

          Dear Channy,

          you saved my day! At least after changing the Realm of the "Additional Credentials" to the simplified form "svn+ssh://server-name" which you provided, it looks quite promising that it finally works for me.

          Best regards and thanks for the thorough analysis.

          Markus Franke added a comment - Dear Channy, you saved my day! At least after changing the Realm of the "Additional Credentials" to the simplified form "svn+ssh://server-name" which you provided, it looks quite promising that it finally works for me. Best regards and thanks for the thorough analysis.

          Hello,

          for me it's works with svn+ssh but not with https.
          I try to add :
          {{additionalCredentials: [
          [realm: 'My Realm SVN',
          credentialsId: 'myId'],
          [realm: 'https://192.168.XX.YY:443',
          credentialsId: 'myId'],
          [realm: 'https://192.168.XX.YY',
          credentialsId: 'myId']
          ]}}
          And i still have:
          {{hudson.util.IOException2: revision check failed on https://192.168.XX.YY/repos/svnflow/project/trunk/server/com.project.server.webapp
          at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:208)
          at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:138)
          at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
          at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
          at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
          at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83)
          at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73)
          at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:52)
          at hudson.security.ACL.impersonate(ACL.java:213)
          at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:49)
          at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
          at java.util.concurrent.FutureTask.run(FutureTask.java:266)
          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
          at java.lang.Thread.run(Thread.java:745)
          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:66)
          at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:798)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:391)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:862)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:698)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:118)
          at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1049)
          at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:189)
          at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119)
          at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:195)
          at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:46)
          at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
          at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
          at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
          at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
          at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
          at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968)
          at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873)
          at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:194)
          ... 14 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:728)
          ... 32 more
          Finished: FAILURE}}

          My versions are:

          • Jenkins 2.7.3
          • SVN plugin 2.7.1

          So how, i can help you better? (Maybe I can try to do PR, if i can restart the production jenkins in java remot debug....)

          Guillaume Dufour added a comment - Hello, for me it's works with svn+ssh but not with https. I try to add : {{additionalCredentials: [ [realm: 'My Realm SVN', credentialsId: 'myId'], [realm: 'https://192.168.XX.YY:443', credentialsId: 'myId'], [realm: 'https://192.168.XX.YY', credentialsId: 'myId'] ]}} And i still have: {{hudson.util.IOException2: revision check failed on https://192.168.XX.YY/repos/svnflow/project/trunk/server/com.project.server.webapp at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:208) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:138) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:52) at hudson.security.ACL.impersonate(ACL.java:213) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:49) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) 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:66) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:798) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:391) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:862) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:698) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:118) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1049) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:189) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:195) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:46) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:194) ... 14 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:728) ... 32 more Finished: FAILURE}} My versions are: Jenkins 2.7.3 SVN plugin 2.7.1 So how, i can help you better? (Maybe I can try to do PR, if i can restart the production jenkins in java remot debug....)

          Guillaume Dufour added a comment - - edited

          Hello, I try to reproduce with a unit test directly on my svn server. com.myapp.server contains 2 externals : com.myapp.server.webapp and another one. But the error not occured.
          The changelog file is always empty (<log/>) maybe i must do another previous call to feed it.
          How this following test is different as a checkout directly by jenkins 2 ? :

          {{
          @Test(timeout = 0L)
          public void testCheckoutHttpsWithExternalsAndAuthentification() throws Exception {
          SystemCredentialsProvider.getInstance().setDomainCredentialsMap(Collections.singletonMap(Domain.global(),
          Arrays.<Credentials>asList(
          new UsernamePasswordCredentialsImpl(CredentialsScope.GLOBAL, "1-login", null, "mylogin", "mypassword")
          )
          ));

          List<SubversionSCM.ModuleLocation> locations = Arrays.asList(
          new SubversionSCM.ModuleLocation("https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server", "1-login",".", SVNDepth.INFINITY.getName(), false)
          );
          List<SubversionSCM.AdditionalCredentials> additionalCredentials = Arrays.asList(
          new SubversionSCM.AdditionalCredentials("Realm of SVN","1-login"),
          new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY:443","1-login"),
          new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY","1-login"),
          new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY/repos/svnflow","1-login"),
          new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server.webapp","1-login")
          );
          SCM scm = new SubversionSCM(locations, new UpdateUpdater(), null, null, "", "", "", "", false, false, additionalCredentials);
          SCMSource source = new SingleSCMSource(null, "https://192.168..XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server", scm);
          TaskListener listener = StreamTaskListener.fromStdout();
          // First check fetching of all heads. SCMHeadObserver.Collector.result is a TreeMap so order is predictable:
          assertEquals("[SCMHead

          {'https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server'}

          ]", source.fetch(listener).toString());
          // SCM.checkout does not permit a null build argument, unfortunately.
          Run<?,?> run = r.buildAndAssertSuccess(r.createFreeStyleProject());
          // Retrieval of heads:
          FilePath ws = new FilePath(new File("C:\\Users\\gdufour\\AppData\\Local\\Temp\\hudsonFixedtest\\jobs\\test0\\builds
          1")).child("tmp");
          Launcher launcher = new Launcher.LocalLauncher(listener);
          SCMRevisionState scmRevisionState = scm.calcRevisionsFromBuild(run , ws, launcher, listener);
          assertRevision2(source.fetch(new SCMHead("https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server"), listener), "null", source, run, listener, launcher, scmRevisionState);
          }

          private void assertRevision2(@CheckForNull SCMRevision rev, @CheckForNull String expectedFile, @NonNull SCMSource source, @NonNull Run<?,?> run, @NonNull TaskListener listener, Launcher launcher, SCMRevisionState scmRevisionState) throws Exception {
          if (rev == null)

          { assertNull(expectedFile); return; }

          FilePath ws = new FilePath(new File("C:\\Users\\gdufour\\AppData\\Local\\Temp\\hudsonFixedtest\\jobs\\test0\\builds
          1")).child("tmp");
          File changelog = new File("C:\\Users\\gdufour\\AppData\\Local\\Temp\\hudsonFixedtest\\jobs\\test0\\builds\\1
          changelog");
          source.build(rev.getHead(), rev).checkout(run, launcher, ws, listener, changelog, scmRevisionState);
          FilePath file = ws.child("file");
          assertEquals(expectedFile, file.exists() ? file.readToString() : null);
          }}}

          Guillaume Dufour added a comment - - edited Hello, I try to reproduce with a unit test directly on my svn server. com.myapp.server contains 2 externals : com.myapp.server.webapp and another one. But the error not occured. The changelog file is always empty (<log/>) maybe i must do another previous call to feed it. How this following test is different as a checkout directly by jenkins 2 ? : {{ @Test(timeout = 0L) public void testCheckoutHttpsWithExternalsAndAuthentification() throws Exception { SystemCredentialsProvider.getInstance().setDomainCredentialsMap(Collections.singletonMap(Domain.global(), Arrays.<Credentials>asList( new UsernamePasswordCredentialsImpl(CredentialsScope.GLOBAL, "1-login", null, "mylogin", "mypassword") ) )); List<SubversionSCM.ModuleLocation> locations = Arrays.asList( new SubversionSCM.ModuleLocation("https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server", "1-login",".", SVNDepth.INFINITY.getName(), false) ); List<SubversionSCM.AdditionalCredentials> additionalCredentials = Arrays.asList( new SubversionSCM.AdditionalCredentials("Realm of SVN","1-login"), new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY:443","1-login"), new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY","1-login"), new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY/repos/svnflow","1-login"), new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server.webapp","1-login") ); SCM scm = new SubversionSCM(locations, new UpdateUpdater(), null, null, "", "", "", "", false, false, additionalCredentials); SCMSource source = new SingleSCMSource(null, "https://192.168..XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server", scm); TaskListener listener = StreamTaskListener.fromStdout(); // First check fetching of all heads. SCMHeadObserver.Collector.result is a TreeMap so order is predictable: assertEquals("[SCMHead {'https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server'} ]", source.fetch(listener).toString()); // SCM.checkout does not permit a null build argument, unfortunately. Run<?,?> run = r.buildAndAssertSuccess(r.createFreeStyleProject()); // Retrieval of heads: FilePath ws = new FilePath(new File("C:\\Users\\gdufour\\AppData\\Local\\Temp\\hudsonFixedtest\\jobs\\test0\\builds 1")).child("tmp"); Launcher launcher = new Launcher.LocalLauncher(listener); SCMRevisionState scmRevisionState = scm.calcRevisionsFromBuild(run , ws, launcher, listener); assertRevision2(source.fetch(new SCMHead("https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server"), listener), "null", source, run, listener, launcher, scmRevisionState); } private void assertRevision2(@CheckForNull SCMRevision rev, @CheckForNull String expectedFile, @NonNull SCMSource source, @NonNull Run<?,?> run, @NonNull TaskListener listener, Launcher launcher, SCMRevisionState scmRevisionState) throws Exception { if (rev == null) { assertNull(expectedFile); return; } FilePath ws = new FilePath(new File("C:\\Users\\gdufour\\AppData\\Local\\Temp\\hudsonFixedtest\\jobs\\test0\\builds 1")).child("tmp"); File changelog = new File("C:\\Users\\gdufour\\AppData\\Local\\Temp\\hudsonFixedtest\\jobs\\test0\\builds\\1 changelog"); source.build(rev.getHead(), rev).checkout(run, launcher, ws, listener, changelog, scmRevisionState); FilePath file = ws.child("file"); assertEquals(expectedFile, file.exists() ? file.readToString() : null); }}}

          So i debug the plugin and i found why. It's because the format of the realm is not just the realm name but the full name with uri like:
          <https://XX.YY.WW.ZZ:PORT> My Realm Name
          So it's my fault. sorry

          Guillaume Dufour added a comment - So i debug the plugin and i found why. It's because the format of the realm is not just the realm name but the full name with uri like: < https://XX.YY.WW.ZZ:PORT > My Realm Name So it's my fault. sorry

          Jesse Glick added a comment -

          I see no reason for this to have been reopened.

          Jesse Glick added a comment - I see no reason for this to have been reopened.

            recena Manuel Recena Soto
            simabeis Marcel Beister
            Votes:
            43 Vote for this issue
            Watchers:
            75 Start watching this issue

              Created:
              Updated:
              Resolved: