• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None
    • Platform: All, OS: All

      The SVN authentication information needs to be saved in subversions auth folder
      (~\Subversion\auth on windows ?? on unix) so any scripts invoking svn have the
      required authentication available.

      (e.g. M2 Release Plugin)

          [JENKINS-3338] need to share svnauth information

          DefaultSVNAuthenticationManager.PersistentAuthenticationProvider.saveAuthentication
          has the logic to persist the data in a format that SVN CLI understands.

          This class isn't public, so either we rip off the code, or somehow talk to
          DefaultSVNAuthenticationManager to grab an instance.

          The other part of the problem is how to do this on all slaves, even when some
          slaves are offline. It probably needs to be done in the background when a
          credential is entered, plus when a slave is connected, we reapply all
          credentials. Something like that should work.

          Kohsuke Kawaguchi added a comment - DefaultSVNAuthenticationManager.PersistentAuthenticationProvider.saveAuthentication has the logic to persist the data in a format that SVN CLI understands. This class isn't public, so either we rip off the code, or somehow talk to DefaultSVNAuthenticationManager to grab an instance. The other part of the problem is how to do this on all slaves, even when some slaves are offline. It probably needs to be done in the background when a credential is entered, plus when a slave is connected, we reapply all credentials. Something like that should work.

          Messing with a user's SVN setup
          just because the user wants to donate a few CPU cycles to the CI cause
          can be totally unacceptable in some environments.

          See also https://issues.jenkins-ci.org/browse/JENKINS-9657 .

          Andreas Krüger added a comment - Messing with a user's SVN setup just because the user wants to donate a few CPU cycles to the CI cause can be totally unacceptable in some environments. See also https://issues.jenkins-ci.org/browse/JENKINS-9657 .

          James Nord added a comment -

          Any CI system should have their own user account dedicated for just doing CI jobs.

          Doing anything as the same user as a local interactive human user (or sharing the user with any other processes) is likely to cause issues down the line anyway.
          (rm -fr $tmp to clean up space for instance.
          niavly killing all my java processes as my eclipse went awol etc... etc...)

          So "The slave is run on by a person that also happens to be a developer and have SVN access to the repository" is a fundamental flaw in your setup.

          James Nord added a comment - Any CI system should have their own user account dedicated for just doing CI jobs. Doing anything as the same user as a local interactive human user (or sharing the user with any other processes) is likely to cause issues down the line anyway. (rm -fr $tmp to clean up space for instance. niavly killing all my java processes as my eclipse went awol etc... etc...) So "The slave is run on by a person that also happens to be a developer and have SVN access to the repository" is a fundamental flaw in your setup.

            Unassigned Unassigned
            teilo James Nord
            Votes:
            3 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: