• 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
      • etc

       

      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. 

          [JENKINS-53767] Offer plugin management tooling

          Oleg Nenashev added a comment -

          Oleg Nenashev added a comment - FTR https://jenkins.io/projects/gsoc/2019/project-ideas/plugin-installation-manager-tool-cli/  

          Joseph Petersen (old) added a comment - - edited

          In JCasC we ended up removing the plugin management support as it was causing issues on startup. See https://github.com/jenkinsci/configuration-as-code-plugin/pull/769

          Thank you oleg_nenashev for the GSoC write up

          Joseph Petersen (old) added a comment - - edited In JCasC we ended up removing the plugin management support as it was causing issues on startup. See  https://github.com/jenkinsci/configuration-as-code-plugin/pull/769 Thank you oleg_nenashev for the GSoC write up

          Joseph Petersen (old) added a comment - - edited

          From JCasC point of view:

          Should be possible to add an optional JCasC configurator to Jenkins core.
          Reading the configurations at startup and invoke the installation of plugins before ever starting to configure plugins.
          That would at least take care of plugin installation where JCasC is concerned.
          Though it would still require more plugin installation tooling.

          Regarding plugin installation tooling

          I still strongly believe that tooling should either stay within Java or a mix of Java and Go.

          If it was pure Java I could foresee the tool becoming overly large and burden by dependency hell.

          A mix of Go and Java could work.

          Go would be the main source library and has a better native HTTP client.

          Java jar would just be a wrapper for calling go functions: https://medium.com/learning-the-go-programming-language/calling-go-functions-from-other-languages-4c7d8bcc69bf

          Joseph Petersen (old) added a comment - - edited From JCasC point of view: Should be possible to add an optional JCasC configurator to Jenkins core. Reading the configurations at startup and invoke the installation of plugins before ever starting to configure plugins. That would at least take care of plugin installation where JCasC is concerned. Though it would still require more plugin installation tooling. Regarding plugin installation tooling I still strongly believe that tooling should either stay within Java or a mix of Java and Go. If it was pure Java I could foresee the tool becoming overly large and burden by dependency hell. A mix of Go and Java could work. Go would be the main source library and has a better native HTTP client. Java jar would just be a wrapper for calling go functions:  https://medium.com/learning-the-go-programming-language/calling-go-functions-from-other-languages-4c7d8bcc69bf

          > Should be possible to add an optional JCasC configurator to Jenkins core.

          if added to Jenkins Core then JCasC can't be a plugin anymore.

           

          My initial idea was to refactor PluginManager (and siblings) so they can be used as a standalone library for plugin management/installation, then can be either embedded into another tool, or invoked from command line with the adequate `-cp` option pointing to this lib within jenkins.war/WEB-INF/libs.

          I'm also fine with a Go implementation which would make perfect sense for portability in various scenarios. In both cases, a well defined JEP on plugin management in Jenkins would help, as today we have to reverse-engineer the existing codebase to understand plugin management and update-center mysteries.

           

          Nicolas De Loof added a comment - > Should be possible to add an optional JCasC configurator to Jenkins core. if added to Jenkins Core then JCasC can't be a plugin anymore.   My initial idea was to refactor PluginManager (and siblings) so they can be used as a standalone library for plugin management/installation, then can be either embedded into another tool, or invoked from command line with the adequate `-cp` option pointing to this lib within jenkins.war/WEB-INF/libs. I'm also fine with a Go implementation which would make perfect sense for portability in various scenarios. In both cases, a well defined JEP on plugin management in Jenkins would help, as today we have to reverse-engineer the existing codebase to understand plugin management and update-center mysteries.  

          Oleg Nenashev added a comment -

          Just an update here, we will have a GSoC project for it this year: https://summerofcode.withgoogle.com/projects/#5741119520899072

          The format is yet to be defined, but it will be handled under the Platform SIG umbrella.

           

           

          Oleg Nenashev added a comment - Just an update here, we will have a GSoC project for it this year:  https://summerofcode.withgoogle.com/projects/#5741119520899072 The format is yet to be defined, but it will be handled under the Platform SIG umbrella.    

          This might help address the following ansible jenkin plugin management problem: https://github.com/ansible/ansible/issues/24864

          Nicholas Brown added a comment - This might help address the following ansible jenkin plugin management problem: https://github.com/ansible/ansible/issues/24864

          Hi,

          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).

           

          Kind regards

           

          Florian

          Florian Wilhelm added a comment - Hi, 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).   Kind regards   Florian

          Jesse Glick added a comment -

          JENKINS-47498 might be a better input source, as the list of plugins would actually be mechanically vetted, not merely the latest on offer.

          Jesse Glick added a comment - JENKINS-47498 might be a better input source, as the list of plugins would actually be mechanically vetted, not merely the latest on offer.

          Tim Black added a comment -

          Can someone in the know please add a comment about how and where this work was resolved?

          Tim Black added a comment - Can someone in the know please add a comment about how and where this work was resolved?

          Tim Jacomb added a comment -

          Tim Jacomb added a comment - https://github.com/jenkinsci/plugin-installation-manager-tool

            stopalopa Natasha Stopa
            ndeloof Nicolas De Loof
            Votes:
            11 Vote for this issue
            Watchers:
            20 Start watching this issue

              Created:
              Updated:
              Resolved: