Some plugins not updating

[robinbowes]

Hi,

I'm using the 1.0.1 release of this module with PE 3.1.3 on RHEL6.

I'm using the plugin code like this:

create_resources(jenkins::plugin, hiera('jenkins_plugins', {}))

Where "jenkins_plugins" is a hash structure containing something like:

jenkins_plugins:
  'multiple-scms':
    version: '0.3'
  'token-macro':
    version: '1.10'
...

I'm finding that some plugins do not update - it seems to be those that are distributed as plugin_name.hpi, eg. credentials.

When puppet runs, it says it installed the plugin:

Notice: /Stage[main]/Profile_jenkins/Jenkins::Plugin[credentials]/Exec[download-credentials]/returns: executed successfully
Notice: /Stage[main]/Profile_jenkins/Jenkins::Plugin[credentials]/File[/var/lib/jenkins/plugins/credentials.hpi]/owner: owner changed 'root' to 'jenkins'
Notice: /Stage[main]/Profile_jenkins/Jenkins::Plugin[credentials]/File[/var/lib/jenkins/plugins/credentials.hpi]/mode: mode changed '0600' to '0644'
Info: /Stage[main]/Profile_jenkins/Jenkins::Plugin[credentials]/File[/var/lib/jenkins/plugins/credentials.hpi]: Scheduling refresh of Service[jenkins]
Info: /Stage[main]/Profile_jenkins/Jenkins::Plugin[credentials]/File[/var/lib/jenkins/plugins/credentials.hpi]: Scheduling refresh of Service[jenkins]

However, Update Centre still shows the old version and the same code runs again next time puppet runs.

Any ideas?

R.

[matthewbarr]

Any potential dependency change?

[robinbowes]

No, not as far as I can see. I'll check next time I'm with this client (next week now).

Thanks,

R.

[natewarr]

I'm experiencing this same issue.

[natewarr]

This happens for core plugins. See https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial#Plugintutorial-Deployingacustombuildofacoreplugin

[jlambert121]

This kind of makes me wonder if we should add a .pinned to each plugin managed by puppet. That would resolve this (I think) and also ensure things defined by puppet are as puppet says.

[tobias-m]

Fixed this issue by changing:

--- a/manifests/plugin.pp
+++ b/manifests/plugin.pp
@@ -78,7 +78,7 @@ define jenkins::plugin(

     file { "${plugin_dir}/${plugin}" :
       require => Exec["download-${name}"],
-      owner   => 'jenkins',
+      owner   => 'root',
       mode    => '0644',
       notify  => Service['jenkins'],
     }

[fipp]

tobias-m: Thank you, that worked!

But I'm struggling to see why ...

File["${plugin_dir}/${plugin}"] requires that Exec["download-{$name}"] is executed before it, which does a rm -rf ${name} ${name}.* && wget --no-check-certificate ${base_url}${plugin}.

As I read the code, the rm deletes both the plugin folder and any file starting with the plugin name (such as swarm.hpi or ldap.jpi), and the wget downloads the new .hpi file for the plugin. After this, Service['jenkins'] is notified, and the plugin folder is populated by Jenkins.

Now, why would it have an impact who (root in your fix, otherwise jenkins) owns this .hpi file prior to the Jenkins service being notified (I assume restarted)?

[natewarr]

This is overriding what jenkins is trying to do with the hpi file. By default, jenkins wants to own and control all of the core modules. Changing the owner to root prevents the jenkins user from managing the file the way it wants to. I imagine there's an empty catch block in the code that's keeping this from blowing up completely. I think the better solution is to add a .pinned file for each core module that jenkins manages. See #131.

[jhoblitt]

I believe this issue should be resolved by #389 so I'm going to close this issue. Please reopen it if the problem is reproducible with the current master.