On Tue, Feb 13, 2018 at 7:03 PM, R. Tyler Croy <ty...@monkeypox.org> wrote:
> I have been thus far deriving jenkins/evergreen from
> jenkins/jenkins simply to inherit some scripts, permissions, and other bits.
Yeah, that makes sense as a way to get things up and running quickly.
Once we have an accepted process for tagging a “release” of “Jenkins
Essentials” as a whole, as implied by
then we can rewrite the image to handle core consistently.
>> I do not think it is wise to try to automagically detect a cloud
>> environment. […]
> […what are your concerns] regarding
> a singular "all-in-one" package which can include the necessary
> auto-configuration tooling?
A general distrust of anything magical and opaque that might or might
not work depending on factors too complex for users to see or
understand. If we have a recommended way for Jenkins to run in AWS,
polish it up and put it on Marketplace, if possible. If we have a
recommended way for Jenkins to run in a self-managed Kubernetes
cluster, publish an official Helm chart for it. But keep the basic
Docker image, i.e., whatever happens when I run something like
docker run --rm -v jh:/var/jenkins jenkins/evergreen
straightforward and predictable.
If you are worried about discoverability of our preconfigurations, you
can always add an `AdministrativeMonitor` that says something like
> Hey there! From sniffing around, it looks like you are running this Jenkins
> service in Azure, but you are not taking advantage of the preintegration work
> we have done for you.
> For more information, see: https://azuremarketplace.microsoft.com/etc.
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.