Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Labels:
    • Environment:
    • Similar Issues:

      Description

      I'm encountering an issue similar to JENKINS-12514 with Jenkins 1.450.

      Update manager reports that I'm running subversion plugin 1.34 and 1.37 is available. In my plugins folder I can see:

      rw-rw-r-. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.bak
      rw-rw-r-. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.jpi

      I tell Jenkins to install 1.37. Once it's downloaded I can see:

      rw-rw-r-. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.bak
      rw-rw-r-. 1 jenkins jenkins 2103308 Feb 2 15:43 subversion.jpi

      Checking the manifests:

      [jenkins@XXXX plugins]$ unzip -p subversion.bak META-INF/MANIFEST.MF | grep Plugin-Version
      Plugin-Version: 1.34
      [jenkins@XXXX plugins]$ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version
      Plugin-Version: 1.37

      Restart jenkins to apply the changes. At this point, the present files are:

      rw-rw-r-. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.bak
      rw-rw-r-. 1 jenkins jenkins 2105983 Feb 2 15:20 subversion.jpi

      and the manifests:

      [jenkins@XXXX plugins]$ unzip -p subversion.bak META-INF/MANIFEST.MF | grep Plugin-Version
      Plugin-Version: 1.34
      [jenkins@XXXX plugins]$ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version
      Plugin-Version: 1.34

      And update manager still reports 1.34 with 1.37 available.

        Attachments

          Issue Links

            Activity

            Hide
            pmilliken Paul Milliken added a comment - - edited

            I've also just tried with the CVS plugin (1.6 -> 2.0 upgrade) and observe the same behaviour, so it isn't specific to the subversion plugin. Seems more likely to be a generic issue with bundled plugins.

            I've now tried manually creating a subversion.jpi.pinned file, then it seems to work. This doesn't match up with the behaviour described on https://wiki.jenkins-ci.org/display/JA/Pinned+Plugins, which implies that manually updating a pinned bundled plugin should automatically pin it to prevent overwriting.

            Show
            pmilliken Paul Milliken added a comment - - edited I've also just tried with the CVS plugin (1.6 -> 2.0 upgrade) and observe the same behaviour, so it isn't specific to the subversion plugin. Seems more likely to be a generic issue with bundled plugins. I've now tried manually creating a subversion.jpi.pinned file, then it seems to work. This doesn't match up with the behaviour described on https://wiki.jenkins-ci.org/display/JA/Pinned+Plugins , which implies that manually updating a pinned bundled plugin should automatically pin it to prevent overwriting.
            Hide
            pmilliken Paul Milliken added a comment -

            Since 12514 has been re-opened, I'm pretty sure that it's the same underlying cause.

            Show
            pmilliken Paul Milliken added a comment - Since 12514 has been re-opened, I'm pretty sure that it's the same underlying cause.
            Hide
            cschulz C. S. added a comment -

            I have the same problem since 1.450.

            I have tried different ways to force the update, it seems that jenkins is downloading the jpi files from somewhere and there is only the old version available.
            If you delete under plugins subversion and cvs, you would think it fetches the newest one, but that isn't correct.
            It is always the old version.

            Another way I have tried was over the plugin manager, I have downloaded the packages checked the versions from the new jpi files and saved them.
            After that I have stopped jenkins and removed all plugin stuff. I uploaded the new jpi files and started the server.
            But it replaces automatically all jpi files with the old ones and I don't know from where Jenkins is getting them.

            Show
            cschulz C. S. added a comment - I have the same problem since 1.450. I have tried different ways to force the update, it seems that jenkins is downloading the jpi files from somewhere and there is only the old version available. If you delete under plugins subversion and cvs, you would think it fetches the newest one, but that isn't correct. It is always the old version. Another way I have tried was over the plugin manager, I have downloaded the packages checked the versions from the new jpi files and saved them. After that I have stopped jenkins and removed all plugin stuff. I uploaded the new jpi files and started the server. But it replaces automatically all jpi files with the old ones and I don't know from where Jenkins is getting them.
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            Duplicate of JENKINS-12514, which is fixed in 1.450 for Unix and 1.456 for Windows.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - Duplicate of JENKINS-12514 , which is fixed in 1.450 for Unix and 1.456 for Windows.
            Hide
            pmilliken Paul Milliken added a comment -

            Since I reported it on 1.450 in Linux, even if it is a duplicate of 12514, then it wasn't fixed on Linux at that point. I'll retry my test case once 1.456 is released.

            Show
            pmilliken Paul Milliken added a comment - Since I reported it on 1.450 in Linux, even if it is a duplicate of 12514, then it wasn't fixed on Linux at that point. I'll retry my test case once 1.456 is released.
            Hide
            pmilliken Paul Milliken added a comment -

            Just re-tested with a fresh setup of Jenkins 1.456 on Fedora. Very simply setup, just grabbed the .war file and ran it.

            After first startup, the plugin folder contained subversion.jpi, which had a reported version of 1.34

            paul.milliken@besaid ~/.jenkins/plugins $ ls subversion.*
            subversion.jpi
            paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version
            Plugin-Version: 1.34

            Update manager reported that 1.39 was available. Told it to download and install after restart (but not to restart automatically). After the download, had subversion.jpi and subversion.bak (as expected), with the appropriate versions.

            paul.milliken@besaid ~/.jenkins/plugins $ ls subversion.*
            subversion.bak subversion.jpi
            paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version
            Plugin-Version: 1.39
            paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.bak META-INF/MANIFEST.MF | grep Plugin-Version
            Plugin-Version: 1.34

            Restarted jenkins.

            paul.milliken@besaid ~/.jenkins/plugins $ ls subversion.*
            subversion.bak subversion.jpi
            paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version
            Plugin-Version: 1.34
            paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.bak META-INF/MANIFEST.MF | grep Plugin-Version
            Plugin-Version: 1.34

            It looks like the update is still failing to be automatically pinned, resulting in the bundled version overwriting it. Manually pinning the plugin (by creating subversion.jpi.pinned) works.

            Show
            pmilliken Paul Milliken added a comment - Just re-tested with a fresh setup of Jenkins 1.456 on Fedora. Very simply setup, just grabbed the .war file and ran it. After first startup, the plugin folder contained subversion.jpi, which had a reported version of 1.34 paul.milliken@besaid ~/.jenkins/plugins $ ls subversion.* subversion.jpi paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.34 Update manager reported that 1.39 was available. Told it to download and install after restart (but not to restart automatically). After the download, had subversion.jpi and subversion.bak (as expected), with the appropriate versions. paul.milliken@besaid ~/.jenkins/plugins $ ls subversion.* subversion.bak subversion.jpi paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.39 paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.bak META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.34 Restarted jenkins. paul.milliken@besaid ~/.jenkins/plugins $ ls subversion.* subversion.bak subversion.jpi paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.jpi META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.34 paul.milliken@besaid ~/.jenkins/plugins $ unzip -p subversion.bak META-INF/MANIFEST.MF | grep Plugin-Version Plugin-Version: 1.34 It looks like the update is still failing to be automatically pinned, resulting in the bundled version overwriting it. Manually pinning the plugin (by creating subversion.jpi.pinned) works.
            Hide
            jeremyzerr Jeremy Zerr added a comment -

            I can confirm the exact same thing happening on Jenkins 1.457 under RHEL 5.6 when I use the steps above in the previous comment from Paul. 1.34 is the current Subversion version, 1.39 is the one listed as latest.

            I can also confirm that pinning the 1.39 JPI after the download, as Paul did, does in fact work for me too.

            Thanks, Jeremy Zerr

            Show
            jeremyzerr Jeremy Zerr added a comment - I can confirm the exact same thing happening on Jenkins 1.457 under RHEL 5.6 when I use the steps above in the previous comment from Paul. 1.34 is the current Subversion version, 1.39 is the one listed as latest. I can also confirm that pinning the 1.39 JPI after the download, as Paul did, does in fact work for me too. Thanks, Jeremy Zerr
            Hide
            alexlehm Alex Lehmann added a comment -

            fixed with JENKINS-13129

            Show
            alexlehm Alex Lehmann added a comment - fixed with JENKINS-13129
            Hide
            mc1arke Michael Clarke added a comment -

            Last comment indicates this was fixed under another defect. Please reopen and provide details if you believe this is not the case.

            Show
            mc1arke Michael Clarke added a comment - Last comment indicates this was fixed under another defect. Please reopen and provide details if you believe this is not the case.

              People

              • Assignee:
                mc1arke Michael Clarke
                Reporter:
                pmilliken Paul Milliken
              • Votes:
                6 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: