I thought there was agreement to move cloud preconfiguration into dedicated plugins selected according to “flavor”?

About the wizard, I mean we either need to make the current wizard more customizable, or write a brand new one. Because for instance this is highly likely we won't use the "Suggested plugin" part of it (but keep the admin creation one I suppose?).

rtyler can you please slightly clarify some acceptance criterion/UX?

I assume you mean this to work only if the socket is accessible before/while Jenkins is starting? Or do you want Jenkins to get the Docker cloud configuration as soon as the socket is made available?

Also, about "Docker socket", I assume you mean "a Docker daemon is available"? I.e. if the docker socket is not mounted, but DOCKER_HOST is defined, I suppose you want to auto-work too?

batmat, sorry for the vagueness of the ticket. As far as I am concerned the "acceptance criteria" would be that if /var/run/docker.sock is available to Jenkins, that the Docker plugin is automatically configured in order to allow a user to run a "normal" Pipeline now that JENKINS-49861 has been implemented.

If this is something we need a custom plugin to accomplish then I'd like to see some research proving that to be necessary. My hunch is that it would likely be easier for us to leverage existing plugins and then add some smarts into the jenkins/evergreen container to generate the appropriate Configuration as Code.

So I'm starting on this, and starting to think this is not trivially simple. So I think it will likely deserve a JEP on its own.
So I'll prototype something, and use this to write the JEP and have the design validated.

(Thinking: not sure yet where this will go exactly, but the intent would be that we design something that would be possibly reusable outside Essentials, for instance even using the current core war packaging in some form and probably with some prerequisite/limitations).

batmat, that doesn't surprise me

We have a lot of problems we should address in the backlog about wiring some configuration up like this automatically depending on environment, so a broader solution is very likely required. Try to keep in mind where we are in the product development trajectory though

FYI docker generally has either/both of two possible entry points, the unix socket and a TCP socket but there's an environment variable DOCKER_HOST that could point at anything.  e.g. If we're on Windows (with docker-on-Windows) then it'll only be the TCP port that's listening as Windows doesn't do unix sockets.

What I'd suggest is that you refer to the help text for the "Docker Host URI" field (go to manage-jenkins, configure, scroll down to clouds, add a docker cloud, expand cloud details and then open the help text for the Docker Host URI field) and create some magic that goes "If the docker-plugin wouldn't need to be told the Docker Host URI then install the docker plugin".

...also FYI, there are some standard docker templates that could well work "out of the box" without further configuration so, to create a "perfect" user experience, not only would the docker-plugin get installed, but it'd be pre-configured with all three standard templates too

not only would the docker-plugin get installed, but it'd be pre-configured

pjdarton that is definitely our plan. I now have something working locally with that, hoping to push it for review tomorrow (I need to unhack my local config, and not configure things by hand, but at least now I can build with Docker provisioned agents).

We want Jenkins to be usable to build OOTB, not just have a plugin configured indeed.

[...] all three standard templates too

Here I do not understand what you mean. Is there such a thing as standard available Docker templates provided by the plugin? In case I missed it.
Or you mean, there would like 3 or 4 default templates to support the various basic use cases out there?

For now, I'm using a very basic and generic agent label for this, and was planning on providing a single template for now at least. But if you think we can do more and that it would make sense for users, I'm definitely all ears.

There's three templates that get tested by the unit tests in order to verify that all 3 connection methods work.

1. DockerComputerAttachConnectorTest tests the image "jenkins/slave" can connect using the (new-ish) direct connection method.
2. DockerComputerJNLPConnectorTest tests the image "jenkins/jnlp-slave" can connect via JNLP.
3. DockerComputerSSHConnectorTest tests the image "jenkins/ssh-slave" can connect via SSH.

If we're going to do configuration-by-code then the unit-tested configurations are the ones we should use as we're likely to pick up problems with these very quickly.

Given that it's possible to define a disabled template these days (I added that code ) one could define 3 templates and only enable the first.

OK, this has been running for a bit longer than I anticipated. So quick status update: https://github.com/jenkins-infra/evergreen/pull/95 works, but is non-conditional.

I have a conditional activation working on my machine I hope to push later today or tomorrow. I had to refactor the tests so that we use Docker-compose override files to make tests run under different conditions (in that case, mapping the Docker socket, or not).