On Tue, Feb 13, 2018 at 7:04 PM, R. Tyler Croy <ty...@monkeypox.org> 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 jenkinsci-dev+unsubscr...@googlegroups.com. 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.
