Provided plugins overwritten by detached-plugins on startup

[Enrice]

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

[wiccan2]

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.

[Enrice]

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

[wiccan2]

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]

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.-

[ekohl]

In 5fb0dee I made it possible to set the extension. This is at least a step in the right direction. db25b59 does use this in the acceptance tests.