Details

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

      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.

        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: