Somehow a change to a plugin is restarting jenkins quite often #250
Comments
|
As best as I can tell, from reading the puppet manifests, the ghprb plugin isn't being found in the Also, I don't understand why it's not hitting any of the other plugins, if there were something wrong with getting the list of plugins... |
|
All this happened on 1.2.0 of the module. I have updated to 1.3.0 of the puppet module, trying that out. |
|
I think this might have been due to a missing dependency for the |
|
@dkowis, to run facter locally, use |
|
The problem is that a jenkins plugin was missing a dependency, puppet would then put the plugin back, and this would cycle back on itself every 20 minutes. It was just a difficult error to pin down, ultimately my fault for not making sure a jenkins plugin had the proper dependencies. |
|
So I've run into this again. It still claims that the ghprb plugin has something being updated in the exact same way as before, however, we haven't updated the It's resulting in restarting the jenkins service every 30 minutes (on each puppet run.) Is there some way to get more information about why it's deciding to update the plugin? Is there a way to prevent the service from restarting so we can at least have some time to figure out what's going on? |
|
@dkowis what is the output of |
|
We're using 1.16-8, and that's the version on the host, and we aren't actually trying to update anything... A puppet run would look like the following, even though there were no actual changes to the I took out a few things, but here's what is in facter -p: |
|
I suppose the version of |
|
Certainly, it's still |
|
My first guess is that it has something to do with the |
|
This feels related to #219 . I wonder if somehow it's failing to get ahold of the plugins list for |
describe 'when the jenkins_plugins fact is empty' do
let(:params) {{ :version => '1.2.3'}}
let(:facts) {{ :jenkins_plugins => ''}}
it { should_not contain_exec('download-myplug')}
it { should_not contain_file('/var/lib/jenkins/plugins/myplug.hpi')}
endStick this spec in |
|
Nope, I think I've got this backwards, don't I? The |
|
A mitigating factor would be if I could just not have the puppet module manage the service for me. Is there a way to do that? |
|
Also, in the |
|
@dkowis Is this reproducible with the current master? Plugin handling has been reworked a bit. |
* add `manager_user`, `user`, `manage_group`, `group` params to `jenkins` class. * improve consistency of `file` resouce group ownership throughout the module * add 'localstatedir' param to `jenkins` class and consistently use it to set the 'data' base dir throughout the module * Deprecate/noop `username`, `group`, `create_user` params to `jenkins::plugin` define; replaced by `user`,`group`,etc. params to `jenkins` class * Deprecate/noop `plugin_dir` param to `jenkins::plugin`; replaced by `localstatedir` param to `jenkins` class closes voxpupuli#356 -- alternative approach resolves voxpupuli#362 resolves voxpupuli#365 resolves voxpupuli#219 resolves voxpupuli#249 resolves voxpupuli#250
|
I'll give it a shot soonish, I'm not exactly on that project any more, but I'll see what I can do. |
|
@dkowis It would be great if you have the time! |
I have the version of the plugin fixed in the puppet manifest:
But I will see this happen on occasion. I don't know why, because I didn't delete that plugin, or anything else. I don't know why it's getting the plugin again, because it shouldn't be. But this is causing our jenkins to restart in some cases every 20 minutes....
The text was updated successfully, but these errors were encountered: