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

SCM build trigger not working correctly with variables in SVN URL

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • subversion-plugin
    • None

      I tried using variables in my SVN URL with Subversion plug-in 1.29, but now the SCM build trigger triggers a new build on every update check.

      I created two global variables in the Jenkins System Configuration:

      MYSVN_BASE=file:///home/svn/myproject
      MYSVN_BRANCH=trunk

      and in my build job I use

      $MYSVN_BASE/$MYSVN_BRANCH

      as the SVN URL and the SCM build trigger set to check every 15 minutes for updates.

      Despite a nasty "Invalid URL syntax" error marker below the URL field, checking out and building the project works fine. However, the log says:

      Started by an SCM change
      Updating file:///home/svn/myproject/trunk
      At revision 13360
      no revision recorded for $MYSVN_BASE/$MYSVN_BRANCH in the previous build

      And on any subsequent SCM check, the build is triggered with that same message...

          [JENKINS-10628] SCM build trigger not working correctly with variables in SVN URL

          Jos Braaksma added a comment -

          could be the same

          Jos Braaksma added a comment - could be the same

          Rob Johnston added a comment - - edited

          Reproduced in Jenkins 1.427 with SVN Plugin 1.31

          Rob Johnston added a comment - - edited Reproduced in Jenkins 1.427 with SVN Plugin 1.31

          dogfood added a comment -

          Integrated in plugins_subversion #118
          [FIXED JENKINS-10628]SCM build trigger not working correctly with variables in SVN URL.

          sogabe :
          Files :

          • /trunk/hudson/plugins/subversion/src/main/java/hudson/scm/SubversionSCM.java
          • /trunk/hudson/plugins/subversion/src/main/java/hudson/scm/SubversionChangeLogBuilder.java

          dogfood added a comment - Integrated in plugins_subversion #118 [FIXED JENKINS-10628] SCM build trigger not working correctly with variables in SVN URL. sogabe : Files : /trunk/hudson/plugins/subversion/src/main/java/hudson/scm/SubversionSCM.java /trunk/hudson/plugins/subversion/src/main/java/hudson/scm/SubversionChangeLogBuilder.java

          Code changed in jenkins
          User: sogabe
          Path:
          src/main/java/hudson/scm/SubversionChangeLogBuilder.java
          src/main/java/hudson/scm/SubversionSCM.java
          http://jenkins-ci.org/commit/subversion-plugin/a9229e4c041149518d2e310337b7035ae3aba086
          Log:
          [FIXED JENKINS-10628]SCM build trigger not working correctly with variables in SVN URL.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: sogabe Path: src/main/java/hudson/scm/SubversionChangeLogBuilder.java src/main/java/hudson/scm/SubversionSCM.java http://jenkins-ci.org/commit/subversion-plugin/a9229e4c041149518d2e310337b7035ae3aba086 Log: [FIXED JENKINS-10628] SCM build trigger not working correctly with variables in SVN URL.

          Code changed in jenkins
          User: sogabe
          Path:
          src/main/java/hudson/scm/SubversionChangeLogBuilder.java
          src/main/java/hudson/scm/SubversionSCM.java
          http://jenkins-ci.org/commit/subversion-plugin/a9229e4c041149518d2e310337b7035ae3aba086
          Log:
          [FIXED JENKINS-10628]SCM build trigger not working correctly with variables in SVN URL.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: sogabe Path: src/main/java/hudson/scm/SubversionChangeLogBuilder.java src/main/java/hudson/scm/SubversionSCM.java http://jenkins-ci.org/commit/subversion-plugin/a9229e4c041149518d2e310337b7035ae3aba086 Log: [FIXED JENKINS-10628] SCM build trigger not working correctly with variables in SVN URL.

          leojhartiv added a comment -

          I'm still seeing this behavior in Jenkins 1.437 and Subversion Plugin 1.34. I have my Subversion Repository URL configured as: ${03_RELEASE_BRANCH}/application

          My poll SCM setting is: */5 * * * *

          Every 5 minutes, regardless of whether there are new code changes, a build is kicked off. The polling log shows the following:

          Started on Nov 16, 2011 8:25:54 AM
          Workspace doesn't contain ${03_RELEASE_BRANCH}/application. Need a new build.
          Done. Took 18 ms
          Changes found

          Is anyone else seeing this behavior still? Does this Jira need to be re-opened?

          leojhartiv added a comment - I'm still seeing this behavior in Jenkins 1.437 and Subversion Plugin 1.34. I have my Subversion Repository URL configured as: ${03_RELEASE_BRANCH}/application My poll SCM setting is: */5 * * * * Every 5 minutes, regardless of whether there are new code changes, a build is kicked off. The polling log shows the following: Started on Nov 16, 2011 8:25:54 AM Workspace doesn't contain ${03_RELEASE_BRANCH}/application. Need a new build. Done. Took 18 ms Changes found Is anyone else seeing this behavior still? Does this Jira need to be re-opened?

          sogabe added a comment -

          How did you set "03_RELEASE_BRANCH"?

          sogabe added a comment - How did you set "03_RELEASE_BRANCH"?

          leojhartiv added a comment -

          It's set via the global variables in jenkins/config

          leojhartiv added a comment - It's set via the global variables in jenkins/config

          leojhartiv added a comment -

          Note that on checkout the variable is correctly resolved.

          leojhartiv added a comment - Note that on checkout the variable is correctly resolved.

          leojhartiv added a comment -

          Were you able to reproduce the problem? Would you like me to reopen this issue or open a new one?

          Thanks!

          leojhartiv added a comment - Were you able to reproduce the problem? Would you like me to reopen this issue or open a new one? Thanks!

          Alan Birtles added a comment - - edited

          I am still unable to use a build parameter as part of the svn url. Builds work fine but when polling I see:

           
          Started on Jan 6, 2012 3:10:51 PM
          Location 'http://<respository>/${svn_tag}' does not exist
          One or more repository locations do not exist anymore for hudson.model.FreeStyleProject@5a348b27[<project>], project will be disabled.
          Done. Took 0.41 sec
          No changes
          

          I am using jenkins 1.446 with svn plugin 1.37

          Alan Birtles added a comment - - edited I am still unable to use a build parameter as part of the svn url. Builds work fine but when polling I see: Started on Jan 6, 2012 3:10:51 PM Location 'http://<respository>/${svn_tag}' does not exist One or more repository locations do not exist anymore for hudson.model.FreeStyleProject@5a348b27[<project>], project will be disabled. Done. Took 0.41 sec No changes I am using jenkins 1.446 with svn plugin 1.37

          I am seeing the same issue: svn url defined as a global variable in jenkins->config. Polling log shows the same thing as reported and every time it polls, it results in a build. When building, the variable expansion works properly.

          jenkins v1.449, svn plugin v1.37.

          Martin Dessureault added a comment - I am seeing the same issue: svn url defined as a global variable in jenkins->config. Polling log shows the same thing as reported and every time it polls, it results in a build. When building, the variable expansion works properly. jenkins v1.449, svn plugin v1.37.

          Spike Hains added a comment -

          I am also seeing this issue. The project builds when forced but the polling fails and as a result, disables the project.

          Spike Hains added a comment - I am also seeing this issue. The project builds when forced but the polling fails and as a result, disables the project.

          leojhartiv added a comment -

          Any updated on this issue?

          leojhartiv added a comment - Any updated on this issue?

          Spike Hains added a comment -

          We absolutely love the speed, ease of use, and elegance of Jenkins, but not being able to use SCM polling for our QA builds is quite an inconvenience. Is there a workaround perhaps?

          Spike Hains added a comment - We absolutely love the speed, ease of use, and elegance of Jenkins, but not being able to use SCM polling for our QA builds is quite an inconvenience. Is there a workaround perhaps?

          Bela Eröss added a comment -

          The root cause why the global properties are not replaced is actually in jenkins-core, class hudson.model.AbstractBuild, method getEnvironment(...) where the List<Environment> buildEnvironments in this case is null, because the polling method compareRemoteRevisionWith(...) in the subversion plugin class hudson.scm.SubversionSCM tries to gather the information from the last build. You will find my fix attached to this issue, as a Subversion Patch.

          Bela Eröss added a comment - The root cause why the global properties are not replaced is actually in jenkins-core, class hudson.model.AbstractBuild, method getEnvironment(...) where the List<Environment> buildEnvironments in this case is null, because the polling method compareRemoteRevisionWith(...) in the subversion plugin class hudson.scm.SubversionSCM tries to gather the information from the last build. You will find my fix attached to this issue, as a Subversion Patch.

          Bela Eröss added a comment -

          patch to resolve this issue

          Bela Eröss added a comment - patch to resolve this issue

          Spike Hains added a comment -

          Thank you very much Bela! I applied your patch and rebuilt the Subversion plugin and have confirmed that polling now works successfully for SVN urls that contain a variable. We are currently on Jenkins version 1.455. The following was helpful in installing the updated core plugin:
          https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial#Plugintutorial-Deployingacustombuildofacoreplugin

          Thanks again for helping us out with this.

          Spike Hains added a comment - Thank you very much Bela! I applied your patch and rebuilt the Subversion plugin and have confirmed that polling now works successfully for SVN urls that contain a variable. We are currently on Jenkins version 1.455. The following was helpful in installing the updated core plugin: https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial#Plugintutorial-Deployingacustombuildofacoreplugin Thanks again for helping us out with this.

          Alan Birtles added a comment -

          Any chance of getting Bela's patch merged in to Jenkins?

          Alan Birtles added a comment - Any chance of getting Bela's patch merged in to Jenkins?

          Sukrit Khera added a comment -

          When will this patch be released ? Not sure if I am getting a releated issue or not, but apart from checking the status, it also disables our Jenkins build

          Sukrit Khera added a comment - When will this patch be released ? Not sure if I am getting a releated issue or not, but apart from checking the status, it also disables our Jenkins build

          Quintin Kerby added a comment -

          Agreed; this patch would solve the issue. Just voted for this JIRA.

          Quintin Kerby added a comment - Agreed; this patch would solve the issue. Just voted for this JIRA.

          Daniel added a comment -

          I also applied Belas patch and with Spikes URL was able to build my own custom subversion-plugin which is able to expand the globally defined $variables correctly.

          Propably the entries JENKINS-12287 and JENKINS-12450 are also revolving around this issue?

          Two more things i would like to mention concerning this patch/fix in the svn-plugin:

          • Currently my SVN-polling disables the Job where svn-url contains a $variable (propably because it thinks the svn-url containing the $var is invalid)
          • The GUI displays the svn-url containing the $var as invalid and wants to be helpful and tries to hint me to the regular /trunk svn-url

          Daniel added a comment - I also applied Belas patch and with Spikes URL was able to build my own custom subversion-plugin which is able to expand the globally defined $variables correctly. Propably the entries JENKINS-12287 and JENKINS-12450 are also revolving around this issue? Two more things i would like to mention concerning this patch/fix in the svn-plugin: Currently my SVN-polling disables the Job where svn-url contains a $variable (propably because it thinks the svn-url containing the $var is invalid) The GUI displays the svn-url containing the $var as invalid and wants to be helpful and tries to hint me to the regular /trunk svn-url

          Ruben Perez added a comment - - edited

          Ok, I'm completely updated and I'm still having problems with variables in the SVN url... The interface is not recognizing that I entered a variable and is always showing problem and I can't enter my username and password (I have to specify it on the URL). Also, I'm having an exception like:

          INFO: Failed to access subversion repository ${SVNPATH}
          org.tmatesoft.svn.core.SVNException: svn: E125002: Malformed URL '${SVNPATH}'
          at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
          at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
          at org.tmatesoft.svn.core.SVNURL.<init>(SVNURL.java:221)
          at org.tmatesoft.svn.core.SVNURL.parseURIDecoded(SVNURL.java:113)
          at hudson.scm.SubversionSCM$DescriptorImpl.doCheckRevisionPropertiesSupported(SubversionSCM.java:2201)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:597)
          at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288)
          ............

          This is basic stuff for managing different branches and so on.... Please fix it....

          Ruben Perez added a comment - - edited Ok, I'm completely updated and I'm still having problems with variables in the SVN url... The interface is not recognizing that I entered a variable and is always showing problem and I can't enter my username and password (I have to specify it on the URL). Also, I'm having an exception like: INFO: Failed to access subversion repository ${SVNPATH} org.tmatesoft.svn.core.SVNException: svn: E125002: Malformed URL '${SVNPATH}' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.SVNURL.<init>(SVNURL.java:221) at org.tmatesoft.svn.core.SVNURL.parseURIDecoded(SVNURL.java:113) at hudson.scm.SubversionSCM$DescriptorImpl.doCheckRevisionPropertiesSupported(SubversionSCM.java:2201) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) ............ This is basic stuff for managing different branches and so on.... Please fix it....

          Markus Maki added a comment -

          Hi,
          I also got the behaviour mentioned in the bug description. Since I also use global variables for the Job configurations I would appreciate, if someone could link or send a custom subversion-plugin .hpi file where Bela's Patch is applied.

          Markus Maki added a comment - Hi, I also got the behaviour mentioned in the bug description. Since I also use global variables for the Job configurations I would appreciate, if someone could link or send a custom subversion-plugin .hpi file where Bela's Patch is applied.

          hi, i just recognized that you were already aware of my problem (JENKINS-16116).

          i can provide you a patch for:

          • doCommitNotification considers GlobalNodeProperties environment variables before checks of svnUrl
          • repositoryLocationsNoLongerExist check within scmPolling considers GlobalNodeProperties environment variables before checks of svnUrl
          • doCommitNotification does not cut the first 4 characters of SVNUrl in order to Cut the "U " from the "U /your/changed/files" string instead it cuts the first character and trims the string. this was needed for compatibility to either post-commit hook or svn-version (didnt analyze this that precisely)

          Klaus Azesberger added a comment - hi, i just recognized that you were already aware of my problem ( JENKINS-16116 ). i can provide you a patch for: doCommitNotification considers GlobalNodeProperties environment variables before checks of svnUrl repositoryLocationsNoLongerExist check within scmPolling considers GlobalNodeProperties environment variables before checks of svnUrl doCommitNotification does not cut the first 4 characters of SVNUrl in order to Cut the "U " from the "U /your/changed/files" string instead it cuts the first character and trims the string. this was needed for compatibility to either post-commit hook or svn-version (didnt analyze this that precisely)

          sorry about the format changes - was not aware of autoformat of my eclipse

          Klaus Azesberger added a comment - sorry about the format changes - was not aware of autoformat of my eclipse

          provided a pull request for upcoming 1.44 version

          Klaus Azesberger added a comment - provided a pull request for upcoming 1.44 version

          @Markus Maki: you can build your hpi-file from my fork at https://github.com/kazesberger/subversion-plugin

          it contains the upcoming 1.44 code and fixes from me and bela.

          hth

          Klaus Azesberger added a comment - @Markus Maki: you can build your hpi-file from my fork at https://github.com/kazesberger/subversion-plugin it contains the upcoming 1.44 code and fixes from me and bela. hth

          due to my automated formatting the change set caused a lot of conflicts and reduced visibility of the actually small change set, so my pull request got closed.
          -> i rebased the changeset without the formatting-mess. it should be possible to integrate this fixes now.

          Klaus Azesberger added a comment - due to my automated formatting the change set caused a lot of conflicts and reduced visibility of the actually small change set, so my pull request got closed. -> i rebased the changeset without the formatting-mess. it should be possible to integrate this fixes now.

          Luiz Casey added a comment -

          So is this fix in the latest release 1.45 ?

          Luiz Casey added a comment - So is this fix in the latest release 1.45 ?

          kalaiventhan Annadurai added a comment - - edited

          I am using Jenkins version 1.480.3 and quiet period feature is not working when i specify the parameterized variable. Please anybody suggest on this.

          kalaiventhan Annadurai added a comment - - edited I am using Jenkins version 1.480.3 and quiet period feature is not working when i specify the parameterized variable. Please anybody suggest on this.

          Can anyone help me on the above case??? Thanks in advance...

          kalaiventhan Annadurai added a comment - Can anyone help me on the above case??? Thanks in advance...

          Lukas Goormann added a comment - - edited

          Having similar issue with Jenkins 1.568, Subversion Plugin 2.4 and Credentials Plugin 1.14
          when using a variable in the SVN URL and the SCM build trigger. Ouput of the Subversion-Request-Log:

          Started on 23.06.2014 14:27:01
          Received SCM poll call on for RC.TR.app.core.build.All on 23.06.2014 14:27:01
          ERROR: Abfrage der aktuellen Revision schlug fehl für Repository https:// .../correctVariableRepacement
          org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/.../correctVariableRepacement failed
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
          at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020)
          at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180)
          at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
          at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)
          at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
          at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46)
          at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31)
          at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
          at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
          at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
          at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461)
          at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1235)
          at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:78)
          at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26)
          at hudson.remoting.LocalChannel.call(LocalChannel.java:45)
          at hudson.scm.SubversionSCM.compareRemoteRevisionWith(SubversionSCM.java:1415)
          at hudson.scm.SCM.poll(SCM.java:401)
          at hudson.model.AbstractProject._poll(AbstractProject.java:1428)
          at hudson.model.AbstractProject.poll(AbstractProject.java:1331)
          at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:509)
          at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:538)
          at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
          at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
          at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
          at java.util.concurrent.FutureTask.run(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
          at java.lang.Thread.run(Unknown Source)
          Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
          at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
          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)
          ... 33 more
          Done. Took 0,12 Sekunden
          No changes

          Will either one of the provided Patches help here? and how to apply it? or is another fix needed?
          Thanks in advance...

          Lukas Goormann added a comment - - edited Having similar issue with Jenkins 1.568, Subversion Plugin 2.4 and Credentials Plugin 1.14 when using a variable in the SVN URL and the SCM build trigger. Ouput of the Subversion-Request-Log: Started on 23.06.2014 14:27:01 Received SCM poll call on for RC.TR.app.core.build.All on 23.06.2014 14:27:01 ERROR: Abfrage der aktuellen Revision schlug fehl für Repository https:// .../ correctVariableRepacement org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/.../ correctVariableRepacement failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461) at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1235) at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:78) at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26) at hudson.remoting.LocalChannel.call(LocalChannel.java:45) at hudson.scm.SubversionSCM.compareRemoteRevisionWith(SubversionSCM.java:1415) at hudson.scm.SCM.poll(SCM.java:401) at hudson.model.AbstractProject._poll(AbstractProject.java:1428) at hudson.model.AbstractProject.poll(AbstractProject.java:1331) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:509) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:538) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37) 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) ... 33 more Done. Took 0,12 Sekunden No changes Will either one of the provided Patches help here? and how to apply it? or is another fix needed? Thanks in advance...

          Ralf Mühle added a comment -

          Having similar issue with Jenkins 1.591

          Ralf Mühle added a comment - Having similar issue with Jenkins 1.591

          Daniel Beck added a comment -

          The credential problem is JENKINS-23007.

          Daniel Beck added a comment - The credential problem is JENKINS-23007 .

          Resolved in the latest releases of Subversion Plugin.

          Manuel Recena Soto added a comment - Resolved in the latest releases of Subversion Plugin.

            sogabe sogabe
            creckord Carsten Reckord
            Votes:
            36 Vote for this issue
            Watchers:
            41 Start watching this issue

              Created:
              Updated:
              Resolved: