Open fredg02 opened 4 years ago
Currently, here is how plugins are installed/managed between the container images and the running instances:
/usr/share/jenkins/ref/plugins
.plugins-list
file (if any, e.g. https://github.com/eclipse-cbi/jiro/blob/master/instances/technology.cbi/jenkins/plugins-list) and put them in /usr/share/jenkins/ref/plugins
as well. Thus, an instance image has all its plugins in /usr/share/jenkins/ref/plugins
. jenkins.sh
(https://github.com/eclipse-cbi/jiro-masters/blob/master/jiro.libsonnet#L40) is called (https://github.com/eclipse-cbi/jiro-masters/blob/master/Dockerfile#L24) that will first reconcile what's in the image's /usr/share/jenkins/ref/plugins
folder and what's in the actual $JENKINS_HOME/plugins
(which is a persistent volume). In order to be able to remove a plugin, we need to be able to remove it from $JENKINS_HOME/plugins
folder in the persistent volume. I see 3 options:
config.jsonnet
with the list of plugins to be removed (this list could be copied to some specific file in the /usr/share/jenkins/ref/
folder) and we add another responsibility to jenkins.sh
to actually remove the plugins from this file. I'm not a huge fan as the list of plugins to be removed is not something "stable". There is no reason to keep a plugin in this list once it has been removed... It's also quite complicated as we would have to check if the plugins we want to remove are not a dependencies for some other plugins.$JENKINS_HOME/plugins
at each startup, so that the re-conciliation between /usr/share/jenkins/ref/plugins
and $JENKINS_HOME/plugins
is fairly simple: it's just a copy. Of course, it means that we don't support persistent installation of plugins via the UI. We can still test new plugin and install them from the UI, but once the instance is restarted, the plugin is gone if not added to the image. I like that as it's very close to how we handle configuration via JCasC: all manual edits are overridden at restart. Finally, it's much safer as we don't risk removing a plugin that would end up being a dependency of another.@fredg02, WDYT?
I agree on second proposition.
I'd like to propose another option:
Maybe we should learn from this issue: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/3650 Keeping an old version of "maven-plugin" on the jenkins home plugins directory failed jenkins to start. Cleaning directory plugins was the workaround.
Allow uninstalling Jenkins plugins and handle associated permissions (e.g. Gerrit) to avoid JCasC startup errors.
This might become easier with the new Jenkins Plugins Installation Manager CLI Tool/Library: https://jenkins.io/projects/gsoc/2019/plugin-installation-manager-tool-cli/