Hey, Thanks for all the feedback :) @Daniel Beck: Yup, I'm familiar with the limitations of the https://updates.jenkins-ci.org/current/update-center.json file. Thats why I'm thinking of creating a plugin/dependency resolution system that will have to directly download the specific version of a plugin file from update site folder structure https://updates.jenkins-ci.org/download/plugins/*/ or use https://updates.jenkins-ci.org/latest/ if no version restriction is found.
I wasn't aware that pinning was pointless in 2.x so that'll be an interesting problem to deal with. It seems that I'll have to restrict all access to the UpdateCenter for idea #1, or do a hybrid approach with a UpdateCenter subclass as well. @Baptiste Mathus Unfortunately just using an image with locked plugins isn't a long term solution, because we'll have to occasionally update our Jenkins due to required security updates in plugins or the main application. So being able to update plugins, creating a new *.lock file, test the plugin interactions and deploying the *.lock file to existing Jenkins servers is a requirement. I was hoping to stay away from a hybrid approach that used both an executable and a subclass as it makes development and deployment more complicated, decreasing adoption with Jenkins users. Honestly the goal was to create a tool like Bundler/Pip which would just work out of the box for 99% of use cases. Are there other people experiencing the same issue? I'm more than happy to create my own open source solution, but I'd love to base it on an existing (even unmaintained) project. -Jason On Thursday, August 11, 2016 at 4:51:07 PM UTC-4, Baptiste Mathus wrote: > > IMO a Docker image with the right set of plugins you've tested, plus the > security config you're talking about about forbidding any upgrade would > seem a simpler way. And probably it would your life simpler if you somehow > have to support all those different instances which can currently be > actually quite different. > > HTH > > Le 11 août 2016 3:14 PM, "Jason Kulatunga" <darkm...@gmail.com > <javascript:>> a écrit : > > Hey Jenkins-Users, > > I manage almost a dozen Jenkins servers and our team has been having some > issues with plugin management: such as locking our new installations to > known working versions of some troublesome Jenkins plugins. > We use chef + Jenkins DSL to completely automate the initial installation > of Jenkins, but we're not exactly thrilled with the way the Chef cookbook > handles plugin installation and we've also verified that > 'installNecessaryPlugins' does not actually respect the version parameter. > > curl -XPOST > http://192.150.23.105:8080/pluginManager/installNecessaryPlugins -d > '<install plugin="favorite@1.7" />' > > As such I've started looking into alternative means of locking plugins in > an automated way during installation and I've come up with the following > ideas: > > # An External Dependency Management Tool, eg Bundler, Pip, Berkshelf > Basically an executable that would: > > 1. retrieve a list of all plugins installed in a specific Jenkins > server using the API, and add them to a dependency graph (with metadata: > installed, pinned, enabled, version) > 2. look for a dependency config file (like Gemfile, Berksfile, > requirements.txt) > 3. iterate through all the uninstalled plugins in the dep config file > and add them (and their dependencies) to the dependency graph > 4. solve the graph by ensuring that no pinned/locked version conflicts > occur. > 5. download all uninstalled plugins directly from > https://updates.jenkins-ci.org/ > 6. using the Jenkins api, pin any version locked plugins specified in > the dependency config file. > 7. write the solved dependency graph to the filesystem (eg > Berksfile.lock, Gemfile.lock) (and use it for any subsequent installs if > no > plugins have changed) > 8. disable all permissions to the update center in Jenkins so no users > enable/update plugins manually. > > # UpdateCenter Override > > 1. subclass the default Jenkins UpdateCenter, and tell Jenkins to use > it using a JVM property > 2. override the UpdateCenter.InstallationJob constructor to download > the plugin version specified from the dependency config lock file if it > exists or install like normal and then generate/update a dependency config > lock file with every operation. > 3. listen to the pin event in the PluginCenter and update the > dependency config lock file. > > I'm not sure if anyone has done something similar but I wanted to get some > feedback before I spent too much time investigating either idea. > > Any and all feedback is welcome > > -Jason > Build Automation Engineer > Adobe > > > > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jenkinsci-use...@googlegroups.com <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/2d4f0e32-7d6a-4159-9635-51df7ff83643%40googlegroups.com > > <https://groups.google.com/d/msgid/jenkinsci-users/2d4f0e32-7d6a-4159-9635-51df7ff83643%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/039bfef7-8b69-4312-8b01-127a1480cbaa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
