Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugins are installed each time and restarting service #219

Closed
iax7 opened this issue Nov 20, 2014 · 7 comments · Fixed by #396 or fengor/puppet-jenkins#1
Closed

Plugins are installed each time and restarting service #219

iax7 opened this issue Nov 20, 2014 · 7 comments · Fixed by #396 or fengor/puppet-jenkins#1
Labels
bug Something isn't working
Milestone

Comments

@iax7
Copy link
Contributor

iax7 commented Nov 20, 2014

Every time puppet runs, the plugin installation is run even when it already exists, causing a service restart each time...

@rtyler
Copy link

rtyler commented Nov 26, 2014

@iax7 do you have an example of the logs from the Puppet run? I'm wondering what it thinks has changed every single Puppet run

@rtyler rtyler added the needs-feedback Further information is requested label Nov 26, 2014
@iax7
Copy link
Contributor Author

iax7 commented Dec 2, 2014

Here is the complete log: http://pastebin.com/24zxw7tp

The interesting part is that owner changed 'root' to 'jenkins':

notice: /Stage[main]/Jenkins::Plugins/Jenkins::Plugin[gitlab-merge-request-jenkins]/Exec[download-gitlab-merge-request-jenkins]/returns: executed successfully
notice: /Stage[main]/Jenkins::Plugins/Jenkins::Plugin[gitlab-merge-request-jenkins]/File[/var/lib/jenkins/plugins/gitlab-merge-request-jenkins.hpi]/owner: owner changed 'root' to 'jenkins'
notice: /Stage[main]/Jenkins::Plugins/Jenkins::Plugin[gitlab-plugin]/Exec[download-gitlab-plugin]/returns: executed successfully
notice: /Stage[main]/Jenkins::Plugins/Jenkins::Plugin[gitlab-plugin]/File[/var/lib/jenkins/plugins/gitlab-plugin.hpi]/owner: owner changed 'root' to 'jenkins'
notice: /Stage[main]/Jenkins::Service/Service[jenkins]: Triggered 'refresh' from 3 events
notice: /Stage[main]/Diamond_project::Jenkins/Exec[wait for Jenkins to be ready]/returns: executed successfully
notice: /Stage[main]/Diamond_project::Jenkins/Exec[wait for Jenkins to be ready]: Triggered 'refresh' from 1 events
notice: /Stage[main]/Diamond_project::Jenkins/Jenkins::User[jenkins]/Exec[create-jenkins-user-jenkins]/returns: executed successfully
notice: /Stage[main]/Jenkins::Security/Exec[jenkins-security-full_control]/returns: executed successfully
notice: Finished catalog run in 89.61 seconds

@rtyler rtyler removed the needs-feedback Further information is requested label Dec 11, 2014
@bartjanssens92
Copy link

I am having the same issue. Here is my log:

=> default: Notice: Compiled catalog for jenkins.telenet.be in environment production in 1.14 seconds
==> default: Notice: /Stage[main]/Main/Node[jenkins]/Jenkins::Plugin[build-flow-plugin]/Exec[download-build-flow-plugin]/returns: executed successfully
==> default: Notice: /Stage[main]/Main/Node[jenkins]/Jenkins::Plugin[build-flow-plugin]/File[/var/lib/jenkins/plugins/build-flow-plugin.hpi]/owner: owner changed 'root' to 'jenkins'
==> default: Notice: /File[/var/lib/jenkins/plugins/build-flow-plugin.hpi]/seluser: seluser changed 'unconfined_u' to 'system_u'
==> default: Notice: /Stage[main]/Jenkins::Service/Service[jenkins]: Triggered 'refresh' from 2 events
==> default: Notice: Finished catalog run in 19.62 seconds

with debug enabled: http://pastebin.com/yvLigvrb

@iax7
Copy link
Contributor Author

iax7 commented Jan 7, 2015

I have researched this a little further, the problem is that the facter ::jenkins_plugins is returning an empty string. In a quick view I didn't find the root issue in that facter.

@richjm
Copy link

richjm commented Feb 23, 2015

This happens if the plugin directory is anything other than "~jenkins/plugins" as this is where lib/puppet/jenkins.rb expects it to be. A quick worked around is symlinking "~jenkins/plugins" to the actual location.

@tstibbs
Copy link
Contributor

tstibbs commented Sep 4, 2015

Note there is a request here that captures the root cause of this (that this module always assumes jenkins is intalled in ~jenkins).

@jhoblitt jhoblitt added the bug Something isn't working label Oct 12, 2015
@jhoblitt jhoblitt added this to the 1.6.0 - Kato milestone Oct 12, 2015
jhoblitt added a commit to jhoblitt/puppet-jenkins that referenced this issue Oct 12, 2015
* 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
jhoblitt added a commit to jhoblitt/puppet-jenkins that referenced this issue Oct 12, 2015
* 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
jhoblitt added a commit to jhoblitt/puppet-jenkins that referenced this issue Oct 12, 2015
* 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
@cjmachado
Copy link

Hi there!
I'm commenting on a closed issue because I believe it's still not fixed. My environment is (fresh install):

OS: CentOS 6.8 x86_64
Ruby: 1.8.7 (2013-06-27 patchlevel 374)
Puppet: 3.8.7
puppet-jenkins: 1.7.0
Jenkins: 1.651.3-1.1
Java: Oracle's 1.7.0_80

When I run puppet for the first time, Jenkins is installed but only the credentials.hpi file (and corresponding .pinned file) is placed in the plugins directory. Plugin file is not uncompressed and due to this, "puppet-jenkins" will always try to install the plugins on each run, because it searches for directories inside the plugins directory (there is none, because the HPI file is not expanded). The code that searches for plugin directories is at lib/facter/jenkins.rb (method "available").
To workaround this issue, I changed the archive resource in plugin.pp to include the following attributes:

extract => true,
extract_path => $jenkins::plugin_dir,
extract_command => "unzip %s -d ${::jenkins::plugin_dir}/${title}",
creates => "${::jenkins::plugin_dir}/${title}",
user => $::jenkins::user,
group => $::jenkins::group,

After running puppet with these changes applied, the plugins directory include several other plugins other than "credentials" and Jenkins no longer restarts.

fengor added a commit to fengor/puppet-jenkins that referenced this issue Jun 26, 2019
required for facter to actually know what plugins are installed. See voxpupuli#219
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
7 participants