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

Create Tag (Tag this build) Not working

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Duplicate
    • Component/s: subversion-plugin
    • Labels:
      None
    • Environment:
      Platform: All, OS: WIndows Server 2012
    • Similar Issues:

      Description

      This is a clone of the original bug, when When attempting a tag after selecting 'Tag this build', the tag fails. This is also related to https://issues.jenkins-ci.org/browse/JENKINS-21797, but I have eliminated that.

      I was able to get it to pump one failure message, but I was not able to capture it. I am restarting the VM to see if it will pump the message again.

      Generally, it fails silently, not pumping any information to the UI or even the event logs (even with the hudson.scm.SubversionSCM log set to 'fine' or higher).

      I can recreate it using Jenkins 1.575 or 1.576 on Windows Server 2012, using the latest of the Subversion plugin, with a working copy of version 1.7.

      The SVN server is "SmartSVN" hosted on a Windows 2012 server. It has the non-configurable convention of requiring serverpath/svn/ before your repo name, and on the log I failed to capture, I saw it complain about /svn/myreponame on the copy.

      There is only one user specified in the Jenkins credentials for SVN, and they have tagging privileges.

      And I tried the workaround from a similar bug, where you:

      1. Connect to the target machine
      2. Run `svn cleanup` & `svn up` on each workspace, specifying the credentials

      But that had no impact on the result.

      There are no credentials stored in my hudson.scm.SubversionSCM.xml file:

      <?xml version='1.0' encoding='UTF-8'?>
      <hudson.scm.SubversionSCM_-DescriptorImpl plugin="subversion@2.4.1">
      <generation>49</generation>
      <mayHaveLegacyPerJobCredentials>false</mayHaveLegacyPerJobCredentials>
      <workspaceFormat>100</workspaceFormat>
      <validateRemoteUpToVar>false</validateRemoteUpToVar>
      <storeAuthToDisk>false</storeAuthToDisk>
      </hudson.scm.SubversionSCM_-DescriptorImpl>

        Attachments

          Issue Links

            Activity

            damono Damon Overboe created issue -
            damono Damon Overboe made changes -
            Field Original Value New Value
            Fix Version/s current [ 10162 ]
            Environment Platform: All, OS: HP-UX Platform: All, OS: WIndows Server 2012
            Description Hudson version 1.227. Stand alone setup running on Winstone.

            When attempting a tag after selecting 'Tag this build', the tag fails with an error:
            Tagging http://subversion/svn/XXXXX/web/project/trunk (rev.19085) to
            http://subversion/svn/XXXXX/web/project/tags/project-30

            Failed to tag

            org.tmatesoft.svn.core.SVNAuthenticationException: svn: Commit failed (details
            follow):

            svn: CHECKOUT of '/svn/XXXXX/!svn/ver/19211/web/project/tags': 403 Forbidden
            (http://subversion)

            at
            org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:84)

            at org.tmatesoft.svn.core.wc.SVNCopyClient.doCopy(SVNCopyClient.java:354)

            at
            hudson.scm.SubversionTagAction$TagWorkerThread.perform(SubversionTagAction.java:167)

            at hudson.model.TaskThread.run(TaskThread.java:77)

            Completed



            The error suggests the user setup within the hudson.scm.SubversionSCM.xml does
            not have the authority to checkout the subversion tags directory revision.

            Further investigation found the user being used for the tag is the user that
            started Hudson in the first instance, and NOT the user declared in the
            hudson.scm.SubversionSCM.xml file. Thus, if the user account that started Hudson
            does not have enough permissions for SVN, then the tagging fails with the above
            error.

            Regards

            Matt Gaunt
            This is a clone of the original bug, when When attempting a tag after selecting 'Tag this build', the tag fails.

            Generally, it fails silently, not pumping any information to the UI or even the event logs (even with the hudson Subversion SCM log set to 'fine' or higher).

            I was able to get it to pump one failure message, but I was not able to capture it. I am restarting the VM to see if it will pump the message again.

            I can recreate it using Jenkins 1.575 or 1.576 on Windows Server 2012, using the latest of the Subversion plugin.


            Original meessage:
            --------

            Hudson version 1.227. Stand alone setup running on Winstone.

            When attempting a tag after selecting 'Tag this build', the tag fails with an error:
            Tagging http://subversion/svn/XXXXX/web/project/trunk (rev.19085) to
            http://subversion/svn/XXXXX/web/project/tags/project-30

            Failed to tag

            org.tmatesoft.svn.core.SVNAuthenticationException: svn: Commit failed (details
            follow):

            svn: CHECKOUT of '/svn/XXXXX/!svn/ver/19211/web/project/tags': 403 Forbidden
            (http://subversion)

            at
            org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:84)

            at org.tmatesoft.svn.core.wc.SVNCopyClient.doCopy(SVNCopyClient.java:354)

            at
            hudson.scm.SubversionTagAction$TagWorkerThread.perform(SubversionTagAction.java:167)

            at hudson.model.TaskThread.run(TaskThread.java:77)

            Completed



            The error suggests the user setup within the hudson.scm.SubversionSCM.xml does
            not have the authority to checkout the subversion tags directory revision.

            Further investigation found the user being used for the tag is the user that
            started Hudson in the first instance, and NOT the user declared in the
            hudson.scm.SubversionSCM.xml file. Thus, if the user account that started Hudson
            does not have enough permissions for SVN, then the tagging fails with the above
            error.

            Regards

            Matt Gaunt
            Hide
            danielbeck Daniel Beck added a comment -

            Please file an issue from scratch instead of cloning a six years old one.

            Explain what the problems you're facing are, in detail.

            Show
            danielbeck Daniel Beck added a comment - Please file an issue from scratch instead of cloning a six years old one. Explain what the problems you're facing are, in detail.
            danielbeck Daniel Beck made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Incomplete [ 4 ]
            damono Damon Overboe made changes -
            Description This is a clone of the original bug, when When attempting a tag after selecting 'Tag this build', the tag fails.

            Generally, it fails silently, not pumping any information to the UI or even the event logs (even with the hudson Subversion SCM log set to 'fine' or higher).

            I was able to get it to pump one failure message, but I was not able to capture it. I am restarting the VM to see if it will pump the message again.

            I can recreate it using Jenkins 1.575 or 1.576 on Windows Server 2012, using the latest of the Subversion plugin.


            Original meessage:
            --------

            Hudson version 1.227. Stand alone setup running on Winstone.

            When attempting a tag after selecting 'Tag this build', the tag fails with an error:
            Tagging http://subversion/svn/XXXXX/web/project/trunk (rev.19085) to
            http://subversion/svn/XXXXX/web/project/tags/project-30

            Failed to tag

            org.tmatesoft.svn.core.SVNAuthenticationException: svn: Commit failed (details
            follow):

            svn: CHECKOUT of '/svn/XXXXX/!svn/ver/19211/web/project/tags': 403 Forbidden
            (http://subversion)

            at
            org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:84)

            at org.tmatesoft.svn.core.wc.SVNCopyClient.doCopy(SVNCopyClient.java:354)

            at
            hudson.scm.SubversionTagAction$TagWorkerThread.perform(SubversionTagAction.java:167)

            at hudson.model.TaskThread.run(TaskThread.java:77)

            Completed



            The error suggests the user setup within the hudson.scm.SubversionSCM.xml does
            not have the authority to checkout the subversion tags directory revision.

            Further investigation found the user being used for the tag is the user that
            started Hudson in the first instance, and NOT the user declared in the
            hudson.scm.SubversionSCM.xml file. Thus, if the user account that started Hudson
            does not have enough permissions for SVN, then the tagging fails with the above
            error.

            Regards

            Matt Gaunt
            This is a clone of the original bug, when When attempting a tag after selecting 'Tag this build', the tag fails. This is also related to https://issues.jenkins-ci.org/browse/JENKINS-21797, but I have eliminated that.

            I was able to get it to pump one failure message, but I was not able to capture it. I am restarting the VM to see if it will pump the message again.

            Generally, it fails silently, not pumping any information to the UI or even the event logs (even with the hudson.scm.SubversionSCM log set to 'fine' or higher).

            I can recreate it using Jenkins 1.575 or 1.576 on Windows Server 2012, using the latest of the Subversion plugin, with a working copy of version 1.7.

            The SVN server is "SmartSVN" hosted on a Windows 2012 server. It has the non-configurable convention of requiring serverpath/svn/ before your repo name, and on the log I failed to capture, I saw it complain about /svn/myreponame on the copy.

            There is only one user specified in the Jenkins credentials for SVN, and they have tagging privileges.

            And I tried the workaround from a similar bug, where you:

            1. Connect to the target machine
            2. Run `svn cleanup` & `svn up` on each workspace, specifying the credentials

            But that had no impact on the result.




            There are no credentials stored in my hudson.scm.SubversionSCM.xml file:

                    <?xml version='1.0' encoding='UTF-8'?>
                        <hudson.scm.SubversionSCM_-DescriptorImpl plugin="subversion@2.4.1">
                      <generation>49</generation>
                      <mayHaveLegacyPerJobCredentials>false</mayHaveLegacyPerJobCredentials>
                      <workspaceFormat>100</workspaceFormat>
                      <validateRemoteUpToVar>false</validateRemoteUpToVar>
                      <storeAuthToDisk>false</storeAuthToDisk>
                    </hudson.scm.SubversionSCM_-DescriptorImpl>
            danielbeck Daniel Beck made changes -
            Resolution Incomplete [ 4 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            danielbeck Daniel Beck made changes -
            Status Reopened [ 4 ] Open [ 1 ]
            Hide
            damono Damon Overboe added a comment -

            I figured cloning the related issue was the right way to go, since that issue was never solved, but was just closed because not enough information was provided to track down the bug?

            Yeah, I should have started with just a local draft before posting. I'm going to update it with a bit more information if I can get a good log output, but it's failing silently, even with the hudson.scm.SubversionSCM log set to 'All'.

            Show
            damono Damon Overboe added a comment - I figured cloning the related issue was the right way to go, since that issue was never solved, but was just closed because not enough information was provided to track down the bug? Yeah, I should have started with just a local draft before posting. I'm going to update it with a bit more information if I can get a good log output, but it's failing silently, even with the hudson.scm.SubversionSCM log set to 'All'.
            Hide
            danielbeck Daniel Beck added a comment -

            Which version of the SVN Tag plugin?

            Show
            danielbeck Daniel Beck added a comment - Which version of the SVN Tag plugin?
            Hide
            damono Damon Overboe added a comment -

            It's actually not the SVN Tag plugin, it's just the plain Subversion plugin, using the manual "Tag this build" that you execute on a successful run.

            It is the same behavior on both version 2.4.1 and and 2.4.3. (The ...scm.xml file from above was before upgrading the plugin)

            <http://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin>

            After restarting the server, I see an error page, but still no log. It simply says:

            Build #36

            Tagging is in progress:

            [Clear Error to Retry]

            I checked the logs before and after clicking the "Clear Error" button and there is nothing for the SCM plugin.

            Show
            damono Damon Overboe added a comment - It's actually not the SVN Tag plugin, it's just the plain Subversion plugin, using the manual "Tag this build" that you execute on a successful run. It is the same behavior on both version 2.4.1 and and 2.4.3. (The ...scm.xml file from above was before upgrading the plugin) < http://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin > After restarting the server, I see an error page, but still no log. It simply says: Build #36 Tagging is in progress: [Clear Error to Retry] I checked the logs before and after clicking the "Clear Error" button and there is nothing for the SCM plugin.
            danielbeck Daniel Beck made changes -
            Fix Version/s current [ 10162 ]
            Affects Version/s current [ 10162 ]
            Component/s subversion [ 15485 ]
            Component/s svn-tag [ 15518 ]
            danielbeck Daniel Beck made changes -
            Summary CLONE - Create Tag (Tag this build) Not working Create Tag (Tag this build) Not working
            Hide
            damono Damon Overboe added a comment -

            Steps I took on the logs:

            1. In log levels and added hudson.scm.SubversionSCM, setting it to Fine,
            2. then tested tagging a successful build. No output.
            3. Back in log levels, I bumped it to All,
            4. Same result as #2,
            5. So I added a new log recorder, set to hudson.scm.SubversionSCM, and level All.
            6. Repeated #2, still no output, and the listener in #5 is empty.
            7. Rebooted
            8. Repeated #2, this time I saw the "Clear Error to Retry" message.

            Show
            damono Damon Overboe added a comment - Steps I took on the logs: 1. In log levels and added hudson.scm.SubversionSCM, setting it to Fine, 2. then tested tagging a successful build. No output. 3. Back in log levels, I bumped it to All, 4. Same result as #2, 5. So I added a new log recorder, set to hudson.scm.SubversionSCM, and level All. 6. Repeated #2, still no output, and the listener in #5 is empty. 7. Rebooted 8. Repeated #2, this time I saw the "Clear Error to Retry" message.
            Hide
            damono Damon Overboe added a comment -

            I'm able to get login failures when adding a new project when I haven't set the credentials yet; those go to both the master log and the SubversionSCM log, but those failures are expected.

            Also for what it's worth, I have the svnmerge plug-in, version 2.3, to create, update, and integrate feature branches, and that works well.

            So, I'm going to try disabling as many plugins as I can on a test server to see if one of them is interfering with the Subversion Plugin to rule that out.

            Show
            damono Damon Overboe added a comment - I'm able to get login failures when adding a new project when I haven't set the credentials yet; those go to both the master log and the SubversionSCM log, but those failures are expected. Also for what it's worth, I have the svnmerge plug-in, version 2.3, to create, update, and integrate feature branches, and that works well. So, I'm going to try disabling as many plugins as I can on a test server to see if one of them is interfering with the Subversion Plugin to rule that out.
            Hide
            danielbeck Daniel Beck added a comment -

            Note that there are known issues in 1.576 that make it barely usable on some instances (JENKINS-24317). Make sure the issue occurs on 1.575.

            Show
            danielbeck Daniel Beck added a comment - Note that there are known issues in 1.576 that make it barely usable on some instances ( JENKINS-24317 ). Make sure the issue occurs on 1.575.
            Hide
            damono Damon Overboe added a comment -

            It does exist on both. I was using 1.575 and was following the advice to not upgrade unless you see a bug.

            Then, I upgraded to 1.576 and it still exists.

            I've been able to work around it for now by installing the SVN Tag plugin; my best guess is it's an issue with not liking the url that's forced on us by VisualSVN http:/path-to-server/svn/yourreponame because I saw some behavior with it that appeared to think that http:/path-to-server/svn/ was the actual repo, whereas that's actually nothing; a web browser will list all of the available repos under that, but clients (command line, TortoiseSVN, SmartSVN) will throw an error.

            I'm trying to figure out how to prove that out; I think what I can probably do is test using the tagger against the archives, which are NOT served by VisualSVN, and compare that behavior against the live ones which are served by it.

            Show
            damono Damon Overboe added a comment - It does exist on both. I was using 1.575 and was following the advice to not upgrade unless you see a bug. Then, I upgraded to 1.576 and it still exists. I've been able to work around it for now by installing the SVN Tag plugin; my best guess is it's an issue with not liking the url that's forced on us by VisualSVN http:/path-to-server/svn/yourreponame because I saw some behavior with it that appeared to think that http:/path-to-server/svn/ was the actual repo, whereas that's actually nothing; a web browser will list all of the available repos under that, but clients (command line, TortoiseSVN, SmartSVN) will throw an error. I'm trying to figure out how to prove that out; I think what I can probably do is test using the tagger against the archives, which are NOT served by VisualSVN, and compare that behavior against the live ones which are served by it.
            Hide
            kamrup Rasmus Pedersen added a comment -

            I'm seeing the same bug using Jenkins 1.588 with the Subversion Plug-in 2.4.4 on one of our servers. We have another server running the same versions but here tagging works. I can't figure out what the difference is between the two though - suggestions on what to look for?

            It's hard to figure out what exactly is wrong since there's no error message.

            Show
            kamrup Rasmus Pedersen added a comment - I'm seeing the same bug using Jenkins 1.588 with the Subversion Plug-in 2.4.4 on one of our servers. We have another server running the same versions but here tagging works. I can't figure out what the difference is between the two though - suggestions on what to look for? It's hard to figure out what exactly is wrong since there's no error message.
            Hide
            kamrup Rasmus Pedersen added a comment -

            Still present on Jenkins 1.590 with Subversion plugin 2.4.5.

            Show
            kamrup Rasmus Pedersen added a comment - Still present on Jenkins 1.590 with Subversion plugin 2.4.5.
            Hide
            kamrup Rasmus Pedersen added a comment -

            After upgrading several other plugins I got the following exception when trying to tag:

            Tagging http://HOSTNAME/svn/PATH/TO/REPO/trunk (rev.123321) to http://HOSTNAME/svn/PATH/TO/REPO/tags/NAME_OF_TAG
            ERROR: Failed to tag
            org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/PATH/TO/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.getRepositoryRoot(DAVRepository.java:132)
            	at org.tmatesoft.svn.core.internal.wc.SVNCopyDriver.copyReposToRepos(SVNCopyDriver.java:194)
            	at org.tmatesoft.svn.core.internal.wc.SVNCopyDriver.setupCopy(SVNCopyDriver.java:627)
            	at org.tmatesoft.svn.core.internal.wc16.SVNCopyClient16.doCopy(SVNCopyClient16.java:440)
            	at org.tmatesoft.svn.core.internal.wc2.remote.SvnNgReposToReposCopy.run(SvnNgReposToReposCopy.java:65)
            	at org.tmatesoft.svn.core.internal.wc2.remote.SvnNgReposToReposCopy.run(SvnNgReposToReposCopy.java:23)
            	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.wc2.SvnRemoteCopy.run(SvnRemoteCopy.java:227)
            	at org.tmatesoft.svn.core.wc.SVNCopyClient.doCopy(SVNCopyClient.java:480)
            	at hudson.scm.SubversionTagAction$TagWorkerThread.perform(SubversionTagAction.java:307)
            	at hudson.model.TaskThread.run(TaskThread.java:127)
            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)
            	... 19 more
            Completed
            

            After changing the description of the credentials and running

            svn --no-auth-cache --config-dir invalid info http://HOSTNAME/svn/PATH/TO/REPO/trunk

            the exception disappeared and tagging fails silently again.

            Show
            kamrup Rasmus Pedersen added a comment - After upgrading several other plugins I got the following exception when trying to tag: Tagging http://HOSTNAME/svn/PATH/TO/REPO/trunk (rev.123321) to http://HOSTNAME/svn/PATH/TO/REPO/tags/NAME_OF_TAG ERROR: Failed to tag org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/PATH/TO/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.getRepositoryRoot(DAVRepository.java:132) at org.tmatesoft.svn.core.internal.wc.SVNCopyDriver.copyReposToRepos(SVNCopyDriver.java:194) at org.tmatesoft.svn.core.internal.wc.SVNCopyDriver.setupCopy(SVNCopyDriver.java:627) at org.tmatesoft.svn.core.internal.wc16.SVNCopyClient16.doCopy(SVNCopyClient16.java:440) at org.tmatesoft.svn.core.internal.wc2.remote.SvnNgReposToReposCopy.run(SvnNgReposToReposCopy.java:65) at org.tmatesoft.svn.core.internal.wc2.remote.SvnNgReposToReposCopy.run(SvnNgReposToReposCopy.java:23) 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.wc2.SvnRemoteCopy.run(SvnRemoteCopy.java:227) at org.tmatesoft.svn.core.wc.SVNCopyClient.doCopy(SVNCopyClient.java:480) at hudson.scm.SubversionTagAction$TagWorkerThread.perform(SubversionTagAction.java:307) at hudson.model.TaskThread.run(TaskThread.java:127) 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) ... 19 more Completed After changing the description of the credentials and running svn --no-auth-cache --config-dir invalid info http://HOSTNAME/svn/PATH/TO/REPO/trunk the exception disappeared and tagging fails silently again.
            Hide
            lwtan78 LW Tan added a comment - - edited

            Realized that the svn authentication depending on the cached of the svn password stored in the user profile. What need to be done is in the OS, try to connect to the said repository and store the encrypted password when asked. You should find a new file created under User/.subversion/svn.simple with the said realm. After that your jenkins should be able to tag without any problem.

            Another way is change the parameter name in the hudson.scm.SubversionTagAction from credentialsId to _.credentialId to enable the parameter value set by the user to be passed into the SVN authentication.

            String credentialsId = parser.get("_.credentialsId");

            Show
            lwtan78 LW Tan added a comment - - edited Realized that the svn authentication depending on the cached of the svn password stored in the user profile. What need to be done is in the OS, try to connect to the said repository and store the encrypted password when asked. You should find a new file created under User/.subversion/svn.simple with the said realm. After that your jenkins should be able to tag without any problem. Another way is change the parameter name in the hudson.scm.SubversionTagAction from credentialsId to _.credentialId to enable the parameter value set by the user to be passed into the SVN authentication. String credentialsId = parser.get("_.credentialsId");
            Hide
            danielbeck Daniel Beck added a comment -

            Realized that the svn authentication depending on the cached of the svn password stored in the user profile. What need to be done is in the OS, try to connect to the said repository and store the encrypted password when asked. You should find a new file created under User/.subversion/svn.simple with the said realm. After that your jenkins should be able to tag without any problem.

            This will override all authentication selected in Jenkins, leading to difficult to investigate problems when using multiple authentications each with only partial access to all Subversion repos used. So while a possible workaround in this case, it has severe, often undesirable side effects.

            Show
            danielbeck Daniel Beck added a comment - Realized that the svn authentication depending on the cached of the svn password stored in the user profile. What need to be done is in the OS, try to connect to the said repository and store the encrypted password when asked. You should find a new file created under User/.subversion/svn.simple with the said realm. After that your jenkins should be able to tag without any problem. This will override all authentication selected in Jenkins, leading to difficult to investigate problems when using multiple authentications each with only partial access to all Subversion repos used. So while a possible workaround in this case, it has severe, often undesirable side effects.
            Hide
            kamrup Rasmus Pedersen added a comment -

            Realized that the svn authentication depending on the cached of the svn password stored in the user profile.

            Does this mean that the username and password you choose for "Credentials for tagging" has no meaning?

            Show
            kamrup Rasmus Pedersen added a comment - Realized that the svn authentication depending on the cached of the svn password stored in the user profile. Does this mean that the username and password you choose for "Credentials for tagging" has no meaning?
            Hide
            sarahwoodall Sarah Woodall added a comment -

            I've just created a new issue https://issues.jenkins-ci.org/browse/JENKINS-26668, which I think describes what is actually going on. I believe "Tag this build" does not take any notice of the credentials set up in Jenkins. It just uses the credentials that the Subversion client has cached for you.

            Show
            sarahwoodall Sarah Woodall added a comment - I've just created a new issue https://issues.jenkins-ci.org/browse/JENKINS-26668 , which I think describes what is actually going on. I believe "Tag this build" does not take any notice of the credentials set up in Jenkins. It just uses the credentials that the Subversion client has cached for you.
            sarahwoodall Sarah Woodall made changes -
            Link This issue is related to JENKINS-26668 [ JENKINS-26668 ]
            recena Manuel Recena Soto made changes -
            Assignee Manuel Jesús Recena Soto [ recena ]
            recena Manuel Recena Soto made changes -
            Link This issue duplicates JENKINS-29225 [ JENKINS-29225 ]
            Show
            recena Manuel Recena Soto added a comment - https://issues.jenkins-ci.org/browse/JENKINS-29225
            recena Manuel Recena Soto made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Duplicate [ 3 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 157299 ] JNJira + In-Review [ 195673 ]

              People

              • Assignee:
                recena Manuel Recena Soto
                Reporter:
                damono Damon Overboe
              • Votes:
                8 Vote for this issue
                Watchers:
                12 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: