puppet-jenkins icon indicating copy to clipboard operation
puppet-jenkins copied to clipboard

Provided plugins overwritten by detached-plugins on startup

Open Enrice opened this issue 5 years ago • 5 comments

Hi. How can the following behaviour be suppressed:

I configure a hash of plugins to be installed like so:

class { 'jenkins': plugin_hash => { <...> } }

I would like the latest versions to be installed. But all plugins listed in the hash that are also packaged in the WAR as detached plugins get downgraded to this respective version. First, puppet correctly copies them as "hpi", but on service start they are deleted and replaced by the "jpi"s from the original WAR, virtually being downgraded.

  • Puppet: 4.10.12
  • Distribution: CentOS 7
  • Module version: 2.0.0
  • jenkins 2.176.2

Enrice avatar Aug 16 '19 11:08 Enrice

I am having this exact issue.

It seems to only be happening with Jenkins 2.176.2 and up, at 2.176.1 all works as you'd expect.

wiccan2 avatar Aug 29 '19 10:08 wiccan2

Correct, 2.176.1 works. However I can confirm that this issue still exists in 2.176.3

Enrice avatar Aug 29 '19 13:08 Enrice

Seems that this relates to https://issues.jenkins-ci.org/browse/JENKINS-57528

The plugins must not be installed as *.hpi files otherwise Jenkins will ignore them.

wiccan2 avatar Aug 29 '19 14:08 wiccan2

By making the following changes to manifests/plugin.pp I was able to successfully build a Jenkins Master at 2.176.3

@@ -99,7 +99,7 @@
   }

   $plugin_ext = regsubst($download_url, '^.*\.(hpi|jpi)$', '\1')
-  $plugin     = "${name}.${plugin_ext}"
+  $plugin     = "${name}.jpi"
   # sanity check extension
   if ! $plugin_ext {
     fail("unsupported plugin extension in source url: ${download_url}")
@@ -122,29 +122,6 @@
       default => absent,
     }

-    # at least as of jenkins 1.651, if the version of a plugin being downloaded
-    # has a .hpi extension, and there is an existing version of the plugin
-    # present with a .jpi extension, jenkins will actually delete the .hpi
-    # version when restarted. Essentially making it impossible to
-    # (up|down)grade a plugin from .jpi -> .hpi via puppet across extension
-    # changes.  Regardless, we should be relying on jenkins to guess which
-    # plugin archive to use and cleanup any conflicting extensions.
-    $inverse_plugin_ext = $plugin_ext ? {
-      'hpi'   => 'jpi',
-      'jpi'   => 'hpi',
-    }
-    $inverse_plugin     = "${name}.${inverse_plugin_ext}"
-
-    file {[
-      "${::jenkins::plugin_dir}/${inverse_plugin}",
-      "${::jenkins::plugin_dir}/${inverse_plugin}.disabled",
-      "${::jenkins::plugin_dir}/${inverse_plugin}.pinned",
-    ]:
-      ensure => absent,
-      before => Archive[$plugin],
-    }
-
-
     # Allow plugins that are already installed to be enabled/disabled.
     file { "${::jenkins::plugin_dir}/${plugin}.disabled":
       ensure  => $enabled_ensure,

I also tested updating and downgrading a plugin and all seemed to work.

-I'm not able to make a Pull Request from work for this but might be able to get one done at home tonight.-

wiccan2 avatar Aug 29 '19 15:08 wiccan2

In https://github.com/voxpupuli/puppet-jenkins/commit/5fb0dee289343b9e32e5bcadd7c3ab11d9c751d7 I made it possible to set the extension. This is at least a step in the right direction. https://github.com/voxpupuli/puppet-jenkins/commit/db25b59fd2d4f5bd3b52998e781f72ff655d16c6 does use this in the acceptance tests.

ekohl avatar Sep 03 '20 15:09 ekohl