Baptiste Mathus, 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).