• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major

      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.

          [JENKINS-12632] Subversion plugin update fails

          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.

          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.

          Paul Milliken added a comment -

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

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

          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.

          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.

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

          Kohsuke Kawaguchi added a comment - Duplicate of JENKINS-12514 , which is fixed in 1.450 for Unix and 1.456 for Windows.

          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.

          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.

          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.

          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.

          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

          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

          Alex Lehmann added a comment -

          fixed with JENKINS-13129

          Alex Lehmann added a comment - fixed with JENKINS-13129

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

          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.

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

              Created:
              Updated:
              Resolved: