Status: Resolved (View Workflow)
Plugin Management tooling
Jenkins does offer a web UI to manage plugin installation from a live master instance, but in many deployments administrator would like to control installed plugins by version and by tooling, before jenkins master starts.
- docker official image provides an install-plugins.sh script which evolved far beyond its initial "help script" scope.
- configuration-as-code implemented plugin installation hack based on PluginSite.Plugin#deploy. (Removed as of v1.8 of JCasC plugin)
- open-source update center does expose plugins-version.json on casc request so one can manage versions for all hosted plugins, not just latest
- custom war packager does support plugin installation on his own
- jenkins evergreen does manage plugin installation based on updates from metadata server, using his own logic implemented by nodejs evergreen client.
- jenkinsfile-runner does manage plugin installation implemented in Go
- coreOS provides a groovy script to handle required plugins
- cloudbees DEV@Cloud uses a set of Chef Ruby recipes for the same purpose
Everybody is re-inventing the wheel, partially implementing the "details" of plugin management (signed metadata, artifacts checksums, plugins detached from core, ...). It becomes obvious Jenkins should provide adequate tooling for plugin installation outside a live Jenkins instance.
- relates to
JENKINS-53506 Update all installed plugins to latest version
JENKINS-51929 Create "mvn incrementals:update" equivalents for YAML and BOM definitions
- links to
I like the idea of this project quite a lot, cool stuff.
I have one potential use case where I don’t find a ticket matching it.
For context, I work at SAP and we have a Jenkins image based on upstream with a custom plugins.txt file. Currently we use latest of all plugins. What I would like is to feed that plugins list into the tool and get a now up to date plugins.txt with all dependencies resolved and versions fixed, so we can use that to build a reproducible image. So, instead of a directory where the plugins are installed, my desired output is a “resolved” plugins.txt file. Is this in scope for this project? I think most required code is already there, and thus implementation should not be too much work (looking at PluginManager.java from a birds eye view).
JENKINS-47498 might be a better input source, as the list of plugins would actually be mechanically vetted, not merely the latest on offer.
Can someone in the know please add a comment about how and where this work was resolved?
This might help address the following ansible jenkin plugin management problem: https://github.com/ansible/ansible/issues/24864