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!”
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 view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.