Do not ensure plugin_parent_dir to be a directory (#148) #149
Conversation
when dealing about plugin installation. Firstly, it is not plugin.pp business, but more importantly, if this directory is a symlink, it may break the whole installation.
|
Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests |
|
These two commits merge and test properly on the current master. Is there a philosophical reason why the plugin class has this behavior that keeps this from being merged? Two issues are being corrected here:
|
The management of the basic dependencies of a Jenkins plugin should not be unnecessarily forced on the user. This change adds a new boolean parameter, `$manage_dependencies`, to allow the user to specify whether or not jenkins::plugin will create these dependencies. The default is true to support backwards compatibility. When set to false, the `/var/lib/jenkins` directory, the jenkins user and the jenkins group are expected to be defined elsewhere or already exist. In addition, the plugin_parent_dir resource is checked for a previously defined resource before being created in the same way that the plugin_dir, user and group are checked. Specific tests were created for the new parameter and they verify that plugin_dir is created whether `$manage_dependencies` is true or false. This fixes voxpupuli#148 in a more backwards compatible way than voxpupuli#149.
The management of the basic dependencies of a Jenkins plugin should not be unnecessarily forced on the user. This change wraps the plugin_parent_dir resource creation in a `defined` function to allow the user to create the Jenkins home directory themselves if necessary. This fixes voxpupuli#148 in a more backwards compatible way than voxpupuli#149.
|
Perhaps you could change the |
|
@jchristi see https://docs.puppetlabs.com/references/latest/type.html#file-attribute-ensure
This means it will create a file, and not a directory, if nothing exists. If we want to keep this clause (and we don't), why have it wrong? A clause saying "ok, if there is notings, create a directory, if not, do nothing" would work, be does not exist in Puppet. |
|
Any update ? This has been proposed 2 months ago. No objection has been given. What's going on ? |
The management of the basic dependencies of a Jenkins plugin should not be unnecessarily forced on the user. This change wraps the plugin_parent_dir resource creation in a `defined` function to allow the user to create the Jenkins home directory themselves if necessary. This fixes voxpupuli#148 in a more backwards compatible way than voxpupuli#149.
|
I'm pretty sure this can be considered resolved at this point |
|
@rtyler no, it is not. If I migrate to jenkinsci version of the module, my /var/lib/jenkins symbolic link is deleted, replaced by a new one.
|
|
@turb perhaps an acceptable workaround would be to have the Puppet code using the file { '/var/lib/jenkins':
ensure => link,
target => '/mnt/jenkins',
} |
|
@rtyler I did not understood the intention behind this modification. In fact we did not manage this file with Puppet; now we do. And yes, it does work for us. |
when dealing about plugin installation.
Firstly, it is not plugin.pp business, but more importantly, if this directory is a symlink, it may break the whole installation.
See #148