Docker: Enhancement: Manage Jenkins Plugins Entirely with install-plugins.sh & plugins.txt file

[esterkin]

Currently the included install-plugins.sh script, when used with a plugins.txt file, performs two things:

1) Adds a new plugin if it's present in plugins.txt and doesn't exist on the container.
2) Upgrades a plugin if the plugin version in plugins.txt is higher than the plugin version on the container.

It does not:

3) Downgrade a plugin if the plugin version in plugins.txt is lower than the plugin version on the container.
4) Remove a plugin from the container if it's not present in the plugins.txt file.

The addition of 3 and 4 would allow Jenkins plugins to be managed entirely with install-plugins.sh and plugins.txt. Would it be possible to add a flag passed to install-plugins.sh (e.g. override=true) which would make sure that the only plugins and their versions present in Jenkins are the ones present in the plugins.txt file if managing plugins with the Plugin Manager UI is never used?

[batmat]

Not sure how you are using this script exactly. AFAIK its use case is only for use during docker build, are you using it at runtime?

I don't understand how you would have plugins "already present", as docker build will always start fresh by definition.

Care to clarify? Thanks!

[hoshsadiq]

@batmat I think there's a usecase for it, it can be run at runtime. One example is if you have Kubernetes and use initcontainers (helm for example does this) to install plugins, but also, you could potentially make sure the volume always stays alive, and so restarting the same containers would pick that volume up, and the plugins would still be available. If I haven't explained it properly, let me know and I'll happily expand

[carlossg]

you should check the jenkins Config as Code plugin for that

[tzoratto]

hi @batmat :)

I came across the same use case I think : let's say you want to handle jenkins installation/configuration entirely through code (and docker), the recommended way to do so (based on what I've found so far, correct me if I am wrong) is :

• extend this official docker image
• configure everything you can with the configuration as code plugin
• install plugins you want with install-plugins.sh (as plugin installation through configuration as code plugin is still in beta and not recommended)
• define a docker volume for jenkins home to keep data around

Then, you end up with your fresh jenkins instance, configured exactly as you want, with plugins you want, so far so good. You can update the configuration within the configuration as code plugin files and it will update jenkins configuration accordingly when you will reattach the new container to the existing jenkins home volume, again, so far so good. But regarding the plugins, if you want to uninstall or to downgrade one of them, you have no way to do so apart from doing it through the UI

As far as I understand the code for plugins installation support in configuration as code plugin (https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/plugin/src/main/java/io/jenkins/plugins/casc/plugins/PluginManagerConfigurator.java) it doesn't support plugin uninstallation (and I'm not sure for plugin downgrading) so this issue is valid in my opinion even though I have no idea if it should be handled by install-plugins.sh or by something else.

[batmat]

Hello :-)! I believe this is pretty dangerous to do (mainly the downgrading) given how Jenkins works.

However, the Jenkins community is aware there's an more global problem statement around plugin management. This Epic has been filed some time ago as JENKINS-53767 and also proposed as a "Google Summer Of Code" Idea: https://jenkins.io/projects/gsoc/2019/project-ideas/plugin-installation-manager-tool-cli/ (if you know a good student ;-)).

If you are interested to see this move forward, I would strongly recommend anyone here to read https://issues.jenkins-ci.org/browse/JENKINS-53767 to understand the global issue, and once done do not hesitate to add your user stories if you feel they are not reflected there.

Many people, including myself, believe that 1) shell scripting may not be the best language in the world to handle this growing complexity to address so many different use cases and 2) that this has started to be done from so many places that the Jenkins Docker image repository does not look like the right place to do it.

So, I'm tempted to close this issue here. Not because I disagree with the request, but because I believe it has to be handled more globally to avoid keeping growing our technical debt, through https://issues.jenkins-ci.org/browse/JENKINS-53767.