https://github.com/jenkinsci/jep/blob/master/jep/301/README.adoc#plugins
does not make sense to me. A critical benefit of this system as I understood it was that we could deliver a complete software package—including Jenkins core and plugins—as a unit. So why are you treating core and plugins as distinct things? You should either · Package a particular version of core, and of all “essential” plugins, together in a particular version of a Docker image, and have people use a new tag of this image when they want to update anything. That would be the normal way to manage software in Docker, though it appears to contradict your intention of using `evergreen-client` to perform upgrades. or · Have the image contain only the supervisor, and have it download specific versions of Jenkins core and plugins on demand; and update the image itself only when the supervisor changes (presumably rarely). That also bypasses the concern noted in #security as the image would not need to be updated merely because of a core security advisory. https://github.com/jenkinsci/jep/blob/master/jep/300/README.adoc#sane-defaults I do not think it is wise to try to automagically detect a cloud environment. Rather, we should offer variant images which are preconfigured for specific environments like AWS. Or offer startup flags etc. to select such preconfigurations, and tailor the installation scripts for those environments to pass the right flag. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0o3N68iK_N3b0jH5g-N3KcfG-9rzgGrk_QXqBQBdP0iA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
