Details

    • Epic Name:
      Plugin Management tooling
    • Similar Issues:

      Description

      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. 

        Attachments

          Issue Links

            Activity

            ndeloof Nicolas De Loof created issue -
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            Thanks for submitting it Nicolas De Loof! I totally agree we should streamline it at some point and offer a single solution

            Show
            oleg_nenashev Oleg Nenashev added a comment - Thanks for submitting it Nicolas De Loof ! I totally agree we should streamline it at some point and offer a single solution
            batmat Baptiste Mathus made changes -
            Field Original Value New Value
            Description Jenkins do offer a web UI to manage plugin installation from a live master instance, but in many deployment 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 it's initial "help script" scope.
             * configuration-as-code implemented plugin installation hack based on PluginSite.Plugin#deploy.
             * open-source update center do expose plugins-version.json on casc request so one can manage versions for all hosted plugins, not just latest
             * custom war packager do support plugin installation on his own
             * jenkins evergreen do manage plugin installation based on updates from metadata server, using his own logic implemented by nodejs evergreen client.
             * jenkinsfile-runner do manage plugin installation implemented in Go
             * coreOS provides a [groovy script|https://github.com/coreos/jenkins-os/blob/master/init.groovy] 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_ jenkins live instance. 
            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.
             * 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|https://github.com/coreos/jenkins-os/blob/master/init.groovy] 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_ jenkins live instance. 
            Hide
            jstrachan James Strachan added a comment - - edited

            I'm a big fan of GitOps and using source code to define what version of jenkins core, dockerfile, plugins and their versions etc that folks wanna use. Then to upgrade a plugin/core its a Pull Request.

            It'd be nice to enumerate all the different ways folks configure jenkins core + plugins + versions via source code to generate/setup their Jenkins server.

            e.g. there's the classic Dockerfile + plugins.txt approach like this...

            https://github.com/garethjevans/jenkins-quickstart01/tree/master/jenkinsConfig/departmentFoo/teamA

            or there's Custom War Packager style:

            https://github.com/garethjevans/jenkins-cwp-quickstart01/blob/master/packager-config.yml#L11

            then there's CasC YAML too.

             

            It shouldn't be too hard to handle those 3 source code formats.  

            Then we could create a plugin for updatebot https://github.com/jenkins-x/updatebot/ to automate the generation of PRs for folks using GitOps to upgrade jenkins and/or plugins using either Evergreen,  incrementals:  https://repo.jenkins-ci.org/incrementals/ or releases: https://repo.jenkins-ci.org/releases/

             

            Show
            jstrachan James Strachan added a comment - - edited I'm a big fan of GitOps and using source code to define what version of jenkins core, dockerfile, plugins and their versions etc that folks wanna use. Then to upgrade a plugin/core its a Pull Request. It'd be nice to enumerate all the different ways folks configure jenkins core + plugins + versions via source code to generate/setup their Jenkins server. e.g. there's the classic Dockerfile + plugins.txt approach like this... https://github.com/garethjevans/jenkins-quickstart01/tree/master/jenkinsConfig/departmentFoo/teamA or there's Custom War Packager style: https://github.com/garethjevans/jenkins-cwp-quickstart01/blob/master/packager-config.yml#L11 then there's CasC YAML too.   It shouldn't be too hard to handle those 3 source code formats.   Then we could create a plugin for updatebot https://github.com/jenkins-x/updatebot/  to automate the generation of PRs for folks using GitOps to upgrade jenkins and/or plugins using either Evergreen,  incrementals:  https://repo.jenkins-ci.org/incrementals/  or releases:  https://repo.jenkins-ci.org/releases/  
            jstrachan James Strachan made changes -
            Assignee James Strachan [ jstrachan ]
            Hide
            ndeloof Nicolas De Loof added a comment -

            Part of the problem here is that those tools rely on the Update Center layout to bake download URL for version of plugins to install, while this layout is not defined by a spec.

            So we need

            1. define|document the plugin update center mechanism (metadata signature, how to retrieve hosted plugin versions and download URL, ...)
            2. offer an implementation that can be used in various installation context

            For (2) I'd like we extract PluginManager into a standalone executable jar so

            •  it can run as a CLI jar and been used in docker images as a replacement for install-plugins script
            • it can be used by custom war packager as an utility library to implement the same need
            • the exact same bits are used by jenkins PluginManager (to enforce consistency)
            Show
            ndeloof Nicolas De Loof added a comment - Part of the problem here is that those tools rely on the Update Center layout to bake download URL for version of plugins to install, while this layout is not defined by a spec. So we need define|document the plugin update center mechanism (metadata signature, how to retrieve hosted plugin versions and download URL, ...) offer an implementation that can be used in various installation context For (2) I'd like we extract PluginManager into a standalone executable jar so  it can run as a CLI jar and been used in docker images as a replacement for install-plugins script it can be used by custom war packager as an utility library to implement the same need the exact same bits are used by jenkins PluginManager (to enforce consistency)
            Hide
            batmat Baptiste Mathus added a comment - - edited

            FWIW, CWP and Evergreen are using (no enforcement/checker yet, so there's probably smallish discrepancies) both use the Bill Of Materials JEP-309: https://github.com/jenkinsci/jep/tree/master/jep/309.

            So we already have the standard format defined. So we should all use it. And if by chance it's deemed to miss some things, then JEP-309 should just be amended so that we agree on something. I agree with Nicolas De Loof this subject of handling Jenkins dependencies is becoming wasteful, fluffier and fluffier with all these variants, and should become a tool on its own so that people stop rewriting the (square) wheel everywhere.

            I've thought about all this just a bit and I wonder technically this should be:

            • I find a tool like this would be good to be usable everwhere easily using CLI, so writing it in Go seems a good direction
            • at the same time, Jenkins ecosystem and consumers would probably need it in Java. Ideally, in that case, even Jenkins core associated logic could be extracted (cannot judge of the associated complexity though) so that really everyone use the same resolver tool. A CLI usable packaged version of this tooling (fatjar or whatever) could then be used:

            Like for Maven dependencies, we need a tool able to:

            • compute a dependency tree without (or with as few as possible) downloads
            • download a whole dependency tree (including optional dependencies or not, here lies some combinatorial too).
            Show
            batmat Baptiste Mathus added a comment - - edited FWIW, CWP and Evergreen are using (no enforcement/checker yet, so there's probably smallish discrepancies) both use the Bill Of Materials JEP-309: https://github.com/jenkinsci/jep/tree/master/jep/309 . So we already have the standard format defined. So we should all use it. And if by chance it's deemed to miss some things, then JEP-309 should just be amended so that we agree on something. I agree with Nicolas De Loof this subject of handling Jenkins dependencies is becoming wasteful, fluffier and fluffier with all these variants, and should become a tool on its own so that people stop rewriting the (square) wheel everywhere. I've thought about all this just a bit and I wonder technically this should be: I find a tool like this would be good to be usable everwhere easily using CLI, so writing it in Go seems a good direction at the same time, Jenkins ecosystem and consumers would probably need it in Java. Ideally, in that case, even Jenkins core associated logic could be extracted (cannot judge of the associated complexity though) so that really everyone use the same resolver tool. A CLI usable packaged version of this tooling (fatjar or whatever) could then be used: in the Docker image builds in Evergreen generation of resolved ingest.json from the essentials.yaml from Jenkins-X's updatebot from CWP ... Like for Maven dependencies, we need a tool able to: compute a dependency tree without (or with as few as possible) downloads download a whole dependency tree (including optional dependencies or not, here lies some combinatorial too).
            Hide
            jglick Jesse Glick added a comment -

            There is already a tool which understands how to update versions of components including incremental versions from a specified branch (such as origin master); as per JENKINS-51929, it would “just” need a shim to also read/write the JEP-309 format. That is only going to be useful, however, if the file is actually listing all the plugins you are bundling, as discussed in JENKINS-53506.

            Show
            jglick Jesse Glick added a comment - There is already a tool which understands how to update versions of components including incremental versions from a specified branch (such as origin master ); as per JENKINS-51929 , it would “just” need a shim to also read/write the JEP-309 format. That is only going to be useful, however, if the file is actually listing all the plugins you are bundling, as discussed in JENKINS-53506 .
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-51929 [ JENKINS-51929 ]
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-53506 [ JENKINS-53506 ]
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            What if we propose it as a GSoC 2019 project idea? If we do so, would somebody be interested to mentor it?

            Show
            oleg_nenashev Oleg Nenashev added a comment - What if we propose it as a GSoC 2019 project idea? If we do so, would somebody be interested to mentor it?
            Hide
            batmat Baptiste Mathus added a comment -

            I'd be ok to co-mentor this subject.

            Show
            batmat Baptiste Mathus added a comment - I'd be ok to co-mentor this subject.
            oleg_nenashev Oleg Nenashev made changes -
            Assignee James Strachan [ jstrachan ]
            oleg_nenashev Oleg Nenashev made changes -
            Labels gsoc-2019-project-idea
            casz Joseph Petersen made changes -
            Description 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.
             * 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|https://github.com/coreos/jenkins-os/blob/master/init.groovy] 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_ jenkins live instance. 
            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|https://github.com/coreos/jenkins-os/blob/master/init.groovy] 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_ jenkins live instance. 
            Show
            oleg_nenashev Oleg Nenashev added a comment - FTR https://jenkins.io/projects/gsoc/2019/project-ideas/plugin-installation-manager-tool-cli/  
            oleg_nenashev Oleg Nenashev made changes -
            Remote Link This issue links to "GSoC Project Idea (Web Link)" [ 22516 ]
            Hide
            casz Joseph Petersen 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

            Show
            casz Joseph Petersen 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
            Hide
            casz Joseph Petersen 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

            Show
            casz Joseph Petersen 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
            Hide
            ndeloof 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.

             

            Show
            ndeloof 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.  
            Hide
            oleg_nenashev 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.

             

             

            Show
            oleg_nenashev 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 Oleg Nenashev made changes -
            Labels gsoc-2019-project-idea gsoc-2019 gsoc-2019-project-idea
            stopalopa Natasha Stopa made changes -
            Assignee Natasha Stopa [ stopalopa ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-57672 [ 199605 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-57800 [ 199751 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-57849 [ 199807 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-57864 [ 199826 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-57865 [ 199827 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-57869 [ 199832 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-57977 [ 199961 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58016 [ 200036 ]
            kwhetstone Kristin Whetstone made changes -
            Epic Child JENKINS-58075 [ 200099 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58076 [ 200101 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58078 [ 200103 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58104 [ 200147 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58107 [ 200150 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58121 [ 200166 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58123 [ 200168 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58126 [ 200171 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58127 [ 200172 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58128 [ 200173 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58129 [ 200174 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58147 [ 200192 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58176 [ 200227 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58191 [ 200246 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58199 [ 200255 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58206 [ 200265 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58216 [ 200276 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58217 [ 200277 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58226 [ 200286 ]
            stopalopa Natasha Stopa made changes -
            Description 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|https://github.com/coreos/jenkins-os/blob/master/init.groovy] 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_ jenkins live instance. 
            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|https://github.com/coreos/jenkins-os/blob/master/init.groovy] 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. 
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58228 [ 200288 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58229 [ 200289 ]
            stopalopa Natasha Stopa made changes -
            Epic Child INFRA-2162 [ 200290 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58242 [ 200305 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58304 [ 200412 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58308 [ 200416 ]
            Hide
            nickbrown Nicholas Brown added a comment -

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

            Show
            nickbrown Nicholas Brown added a comment - This might help address the following ansible jenkin plugin management problem: https://github.com/ansible/ansible/issues/24864
            kwhetstone Kristin Whetstone made changes -
            Epic Child JENKINS-58350 [ 200465 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58389 [ 200513 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58452 [ 200585 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58478 [ 200614 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58537 [ 200686 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58539 [ 200688 ]
            Hide
            fwilhe 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

            Show
            fwilhe 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
            Hide
            jglick 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.

            Show
            jglick 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.
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58608 [ 200769 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58622 [ 200788 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58649 [ 200922 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58652 [ 200932 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58713 [ 201005 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58775 [ 201081 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58821 [ 201133 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-58870 [ 201188 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-59036 [ 201390 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-59042 [ 201396 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-59060 [ 201418 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-59066 [ 201446 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-59148 [ 201583 ]
            stopalopa Natasha Stopa made changes -
            Epic Child JENKINS-59173 [ 201610 ]

              People

              • Assignee:
                stopalopa Natasha Stopa
                Reporter:
                ndeloof Nicolas De Loof
              • Votes:
                8 Vote for this issue
                Watchers:
                17 Start watching this issue

                Dates

                • Created:
                  Updated: