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

"Tag this Build" fails for 1.311+ with SVN Plugin

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Component/s: subversion-plugin
    • Labels:
      None
    • Environment:
      Platform: All, OS: Windows XP
    • Similar Issues:

      Description

      We are running with Subversion SCM and it looks like the tagging feature no
      longer works ("Tag this build".) After a clean restart of Hudson, below is the
      error message you get the first time you try to tag. Subsequent attempts don't
      display anything, it just resets the page. In neither case does the tag actually
      take place in SVN.

      I have tested this in 1.311 as well as 1.314 and the problem continues to
      exists. I haven't tried prior to 1.311 since I don't want to downgrade SVNkit in
      case there's workspace working copy version problems with the downgrade. If I
      had to guess i presume it's something to do with SVNkit upgrade of the new
      isolation of the SVN support in the recent builds?

      ====
      Tagging svn://.../trunk (rev.23689) to svn://.../tags/test

      tried to access field hudson.scm.AbstractScmTagAction.build from class
      hudson.scm.SubversionTagAction$TagWorkerThread

      java.lang.IllegalAccessError: tried to access field
      hudson.scm.AbstractScmTagAction.build from class
      hudson.scm.SubversionTagAction$TagWorkerThread
      at
      hudson.scm.SubversionTagAction$TagWorkerThread.perform(SubversionTagAction.java:204)
      at hudson.model.TaskThread.run(TaskThread.java:116)

      Completed
      ====

        Attachments

          Issue Links

            Activity

            Hide
            lath lath added a comment -

            Added CC

            Show
            lath lath added a comment - Added CC
            Hide
            mindless Alan Harder added a comment -

            what is your JVM/version? I didn't see any problem on OSX with 1.6.0_13

            seems like this access is ok, but I suppose build could be replaced with
            getBuild() to workaround this..

            Show
            mindless Alan Harder added a comment - what is your JVM/version? I didn't see any problem on OSX with 1.6.0_13 seems like this access is ok, but I suppose build could be replaced with getBuild() to workaround this..
            Hide
            hoob hoob added a comment -

            It is running 1.5.0_11 but I tested just now to the same effect with 1.6.0_12.
            Current versions 1.315 and SVN Plugin 1.4 are installed.

            Host OS is Windows XP SP2, container is Tomcat 6, and SVN server is 1.6.3. Any
            logging I can turn on for more information? I tried turning on the SCM logging
            setting, but I don't think it's actually getting to that point given the java
            invokation exception.

            Show
            hoob hoob added a comment - It is running 1.5.0_11 but I tested just now to the same effect with 1.6.0_12. Current versions 1.315 and SVN Plugin 1.4 are installed. Host OS is Windows XP SP2, container is Tomcat 6, and SVN server is 1.6.3. Any logging I can turn on for more information? I tried turning on the SCM logging setting, but I don't think it's actually getting to that point given the java invokation exception.
            Hide
            gecon27 Ioannis Oikonomou added a comment -

            Dear friends,

            We are having exactly the same problem with Hudson ver. 1.315.
            I checked the Internet and it seems that many people are having the same
            problem as of ver. 1.311.
            Could somebody check what can be the problem?

            Thank you very much,
            Ioannis

            Show
            gecon27 Ioannis Oikonomou added a comment - Dear friends, We are having exactly the same problem with Hudson ver. 1.315. I checked the Internet and it seems that many people are having the same problem as of ver. 1.311. Could somebody check what can be the problem? Thank you very much, Ioannis
            Hide
            flominator Flominator added a comment -

            According to http://www.nabble.com/Ver-1.316-and-Tagging-tt24598264.html it
            works with 1.310.

            By the way: I'm having the same problem but without installing a separate
            svnplugin, just by downloading the vanilla war file.

            Show
            flominator Flominator added a comment - According to http://www.nabble.com/Ver-1.316-and-Tagging-tt24598264.html it works with 1.310. By the way: I'm having the same problem but without installing a separate svnplugin, just by downloading the vanilla war file.
            Hide
            nico nico added a comment -

            I can reproduce this using (on Ubuntu)

            java.runtime.name OpenJDK Runtime Environment
            java.runtime.version 1.6.0_0-b14

            java.runtime.name Java(TM) SE Runtime Environment
            java.runtime.version 1.6.0_14-b08

            and 1.6.0_14 on Windows

            Even "Subsequent attempts don't display anything", adding a System.err to the
            catch(Throwable) in TagWorkerThread#perform() shows that this point is reached
            in subsequent attempts, but for some reason the message is not forwarded to the
            ui (and I don't even understand this behaviour - it seems that nothing is
            changed on disk by the first attempt).

            Changing the field-access of "build" to a call to getBuild() causes the tagging
            to work for me, but I'm getting the following stack-trace afterwards:

            WARNUNG: Caught exception evaluating: tags.entrySet. Reason:
            java.lang.ClassCastException: hudson.scm.SubversionSCM$SvnInfo cannot be cast to
            java.lang.String
            java.lang.ClassCastException: hudson.scm.SubversionSCM$SvnInfo cannot be cast to
            java.lang.String
            at java.lang.String.compareTo(String.java:92)
            at java.util.TreeMap.getEntry(TreeMap.java:328)
            at java.util.TreeMap.containsKey(TreeMap.java:209)
            at hudson.util.CopyOnWriteMap.containsKey(CopyOnWriteMap.java:81)
            at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1280)
            ...

            But this may simply be caused by me not properly understanding how to "debug"
            such a thing the "right" way (or hudson overwriting subversion.hpi each time
            it's restartet...)

            I deployed subversion-1.5-SNAPSHOT.hpi to the plugins-directory, touch'ed
            subversion.hpi.disabled, Plugin-Manager is showing 1.4 of the plugin as not active.

            Show
            nico nico added a comment - I can reproduce this using (on Ubuntu) java.runtime.name OpenJDK Runtime Environment java.runtime.version 1.6.0_0-b14 java.runtime.name Java(TM) SE Runtime Environment java.runtime.version 1.6.0_14-b08 and 1.6.0_14 on Windows Even "Subsequent attempts don't display anything", adding a System.err to the catch(Throwable) in TagWorkerThread#perform() shows that this point is reached in subsequent attempts, but for some reason the message is not forwarded to the ui (and I don't even understand this behaviour - it seems that nothing is changed on disk by the first attempt). Changing the field-access of "build" to a call to getBuild() causes the tagging to work for me, but I'm getting the following stack-trace afterwards: WARNUNG: Caught exception evaluating: tags.entrySet. Reason: java.lang.ClassCastException: hudson.scm.SubversionSCM$SvnInfo cannot be cast to java.lang.String java.lang.ClassCastException: hudson.scm.SubversionSCM$SvnInfo cannot be cast to java.lang.String at java.lang.String.compareTo(String.java:92) at java.util.TreeMap.getEntry(TreeMap.java:328) at java.util.TreeMap.containsKey(TreeMap.java:209) at hudson.util.CopyOnWriteMap.containsKey(CopyOnWriteMap.java:81) at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1280) ... But this may simply be caused by me not properly understanding how to "debug" such a thing the "right" way (or hudson overwriting subversion.hpi each time it's restartet...) I deployed subversion-1.5-SNAPSHOT.hpi to the plugins-directory, touch'ed subversion.hpi.disabled, Plugin-Manager is showing 1.4 of the plugin as not active.
            Hide
            nico nico added a comment -

            Created an attachment (id=814)
            Patch, changing references to build by a call to getBuild()

            Show
            nico nico added a comment - Created an attachment (id=814) Patch, changing references to build by a call to getBuild()
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in hudson
            User: : mindless
            Path:
            trunk/hudson/plugins/subversion/src/main/java/hudson/scm/SubversionTagAction.java
            http://fisheye4.cenqua.com/changelog/hudson/?cs=20542
            Log:
            JENKINS-4018 some users report IllegalAccessError when SubversionTagAction
            references "build" field.. this has protected access so should be ok, but
            maybe some jvms have trouble with this now that subversion is a plugin.
            Changed build references to getBuild().

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/hudson/plugins/subversion/src/main/java/hudson/scm/SubversionTagAction.java http://fisheye4.cenqua.com/changelog/hudson/?cs=20542 Log: JENKINS-4018 some users report IllegalAccessError when SubversionTagAction references "build" field.. this has protected access so should be ok, but maybe some jvms have trouble with this now that subversion is a plugin. Changed build references to getBuild().
            Hide
            flominator Flominator added a comment -

            I don't really understand the current status of this. It was included in trunk,
            right? Does that mean, it is also included in 1.320 or only in the nightly builds?

            Show
            flominator Flominator added a comment - I don't really understand the current status of this. It was included in trunk, right? Does that mean, it is also included in 1.320 or only in the nightly builds?
            Hide
            mindless Alan Harder added a comment -

            it is waiting on the next release of the subversion plugin.. I just asked
            kohsuke and he'll release subversion plugin sometime before or with hudson 1.321.

            Show
            mindless Alan Harder added a comment - it is waiting on the next release of the subversion plugin.. I just asked kohsuke and he'll release subversion plugin sometime before or with hudson 1.321.
            Hide
            mindless Alan Harder added a comment -
                • Issue 4262 has been marked as a duplicate of this issue. ***
            Show
            mindless Alan Harder added a comment - Issue 4262 has been marked as a duplicate of this issue. ***
            Hide
            kame kame added a comment -
                • Issue 4200 has been marked as a duplicate of this issue. ***
            Show
            kame kame added a comment - Issue 4200 has been marked as a duplicate of this issue. ***
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            This is released as Subversion plugin 1.5 and will be Hudson 1.321.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - This is released as Subversion plugin 1.5 and will be Hudson 1.321.
            Hide
            kame kame added a comment -

            Works with 1.320 upgrading the Subversion Plugin "by hand". Not sure it's
            recommended though.

            Show
            kame kame added a comment - Works with 1.320 upgrading the Subversion Plugin "by hand". Not sure it's recommended though.
            Hide
            hoob hoob added a comment -

            Confirmed fixed with Hudson 1.321; thanks.

            Show
            hoob hoob added a comment - Confirmed fixed with Hudson 1.321; thanks.

              People

              • Assignee:
                Unassigned
                Reporter:
                hoob hoob
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: