On Tue, Feb 13, 2018 at 7:04 PM, R. Tyler Croy <[email protected]> wrote: > I think making a container > orchestrator a requirement at this point would only inhibit adoption and > learning. I am instead erring on the side of "simple and fast" from a user > perspective, the closest we can get (IMHO) to the `java -jar jenkins.war` > experience, the easier the adoption and experimentation will be
FTR I agree with this approach for the vanilla `jenkins/evergreen` image: having a single, ready-to-run image trumps other considerations. A `docker-run` command can in fact be _easier_ than the traditional Jenkins installation experience because you do not need to even download a WAR and figure out where to put it, install a compatible JRE, etc.; or deal with native package management issues such as version conflicts. We are closer to the old JNLP “Run Now!” button. If we have distinct packagings for more sophisticated environments, as I recommended earlier, then we can define those packagings in a way that more naturally fits those frameworks, for example by keeping the supervisor and Evergreen client in distinct containers in a pod. -- 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/CANfRfr3Tm76SgUnxH_8TSktR%2BE0-7Oz38%2B7Gp65b%3D_e9Aesj3g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
