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

bogus credential in ~/.subversion prevents Hudson from authenticating successfully

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • subversion-plugin
    • None
    • Platform: All, OS: All

      Hello everyone,

      This morning I updated the Subversion plugin to version 1.2 from version 1.1.

      The update didn't go that smooth. Anyway, our Hudson has many jobs (each of them
      has more than 1 SVN location) and after the update one of them started failing.
      Not all, just one, when checking out the second project that it needs.

      Manually downgrading to 1.1 it started working again.

      Checking out [...]
      ERROR: Failed to check out [...]
      org.tmatesoft.svn.core.SVNCancelException: svn: authentication cancelled
      at
      org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60)
      at
      org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
      at
      org.tmatesoft.svn.core.internal.io.dav.DAVUtil.findStartingProperties(DAVUtil.java:126)
      at
      org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getBaselineProperties(DAVUtil.java:216)
      at org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getBaselineInfo(DAVUtil.java:174)
      at
      org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:182)
      at
      org.tmatesoft.svn.core.wc.SVNBasicClient.getRevisionNumber(SVNBasicClient.java:482)
      at org.tmatesoft.svn.core.wc.SVNBasicClient.getLocations(SVNBasicClient.java:851)
      at
      org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:534)
      at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:893)
      at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:791)
      at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:558)
      at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:488)
      at hudson.FilePath.act(FilePath.java:649)
      at hudson.FilePath.act(FilePath.java:633)
      at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:481)
      at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:424)
      at hudson.model.AbstractProject.checkout(AbstractProject.java:803)
      at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:314)
      at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:266)
      at hudson.model.Run.run(Run.java:928)
      at hudson.model.Build.run(Build.java:112)
      at hudson.model.ResourceController.execute(ResourceController.java:93)
      at hudson.model.Executor.run(Executor.java:118)

      Regards, Michal Huniewicz

          [JENKINS-3936] bogus credential in ~/.subversion prevents Hudson from authenticating successfully

          m1ckey created issue -

          nielsull added a comment -

          We have the same issue after upgrading from 1.308 to 1.313 and going to the
          subversion 1.2 plugin. Unfortunately, just downgrading the subversion plugin
          didn't seem to help, so we had to roll back to 1.308.

          nielsull added a comment - We have the same issue after upgrading from 1.308 to 1.313 and going to the subversion 1.2 plugin. Unfortunately, just downgrading the subversion plugin didn't seem to help, so we had to roll back to 1.308.

          m1ckey added a comment -

          Thank you for your input on this one, nielsull.

          We updated to 1.313 - apparently it came with the updated plugin.

          Surprisingly, it fixed some builds and broke others - and they all use the same
          repository locations (different builds of the same projects).

          m1ckey added a comment - Thank you for your input on this one, nielsull. We updated to 1.313 - apparently it came with the updated plugin. Surprisingly, it fixed some builds and broke others - and they all use the same repository locations (different builds of the same projects).

          I reverted to 1.290, which seem to have fixed the problem for me.

          Thomas Diesler added a comment - I reverted to 1.290, which seem to have fixed the problem for me.

          77777777777 added a comment -

          This issue renders Hudson version 1.313 and above completely useless. It breaks
          all of our builds. This is a major BLOCKER.

          77777777777 added a comment - This issue renders Hudson version 1.313 and above completely useless. It breaks all of our builds. This is a major BLOCKER.

          aringa added a comment -

          For us, it is also a major blocker!
          We have been spending days now to fix this - without success.
          Is there any safe path to do a downgrade to a version < 1313 ?

          Some more info from our side:

          • the downgrade to V. 1.1 of the subversion-plugin does NOT solve the problem.
          • the problem does not seem to be node-specific.
          • some projects still work, others not.
          • the problem is not specific to a SVN-repository.

          Mailing list:
          https://hudson.dev.java.net/servlets/BrowseList?list=users&by=thread&from=1865873

          aringa added a comment - For us, it is also a major blocker! We have been spending days now to fix this - without success. Is there any safe path to do a downgrade to a version < 1313 ? Some more info from our side: the downgrade to V. 1.1 of the subversion-plugin does NOT solve the problem. the problem does not seem to be node-specific. some projects still work, others not. the problem is not specific to a SVN-repository. Mailing list: https://hudson.dev.java.net/servlets/BrowseList?list=users&by=thread&from=1865873

          aringa added a comment -

          The problem seems to be resolvable by "wiping out" the workspace of the
          concerned project.

          aringa added a comment - The problem seems to be resolvable by "wiping out" the workspace of the concerned project.
          aringa made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

          awilkins added a comment -

          I tried deleting the project workspace and this did not resolve it (Hudson 1.315
          plus default SVN plugin).

          This is in a job with multiple SVN checkouts configured. It successfully checks
          out the first tree and then fails to authenticate on the second. The server
          reports "unknown username or password" in the log.

          Configuring the credentials succeeds (and fails correctly too with the wrong
          password).

          Both checkouts are from the same repository (same server realm).

          Is this a problem where.. ?

          • The credentials are dropped between SVN sessions
            or
          • The credentials are re-established between sessions but some component of the
            older "stale" authentication gets re-used

          awilkins added a comment - I tried deleting the project workspace and this did not resolve it (Hudson 1.315 plus default SVN plugin). This is in a job with multiple SVN checkouts configured. It successfully checks out the first tree and then fails to authenticate on the second. The server reports "unknown username or password" in the log. Configuring the credentials succeeds (and fails correctly too with the wrong password). Both checkouts are from the same repository (same server realm). Is this a problem where.. ? The credentials are dropped between SVN sessions or The credentials are re-established between sessions but some component of the older "stale" authentication gets re-used

          aringa added a comment -

          We are also running 1315 with (default) SVN-plugin 1.4. The difference seems to
          be that we use only single SVN-URLs in our projects, and hence the
          workspace-wipeout does the job as a workaround.
          Also, we never got "unknown username or password" messages.
          We only got "svn: authentication cancelled" messages.
          I guess this needs to be reproduced with a debugger...

          aringa added a comment - We are also running 1315 with (default) SVN-plugin 1.4. The difference seems to be that we use only single SVN-URLs in our projects, and hence the workspace-wipeout does the job as a workaround. Also, we never got "unknown username or password" messages. We only got "svn: authentication cancelled" messages. I guess this needs to be reproduced with a debugger...

            Unassigned Unassigned
            m1ckey m1ckey
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: