Support docker socket overrides to be set in `~/.testcontainers.properties`
Fixes: #8537
Thanks @myhau. While I think this goes into the right direction, we need to think through how this relates to the current strategy-independent callout to the environment config value in https://github.com/testcontainers/testcontainers-java/blob/6cfaf7b983047cdc52405873f02f8fae7706d668/core/src/main/java/org/testcontainers/DockerClientFactory.java#L165.
So I am wondering if we can solve it in a concise way across strategies (with potentially a better default for many strategies being /var/run/docker.sock rather than our current logic in https://github.com/testcontainers/testcontainers-java/blob/6cfaf7b983047cdc52405873f02f8fae7706d668/core/src/main/java/org/testcontainers/DockerClientFactory.java#L175) and also align the behavior across languages.
@kiview
Thanks for the initial feedback!
I fully understand the need of approaching this holistically and doing the best possible thing for the user.
At the same time, the adoption of alternative container runtimes (Podman, Colima, Rancher) is growing on macOS (and Windows), and the ability to override Docker socket will always be necessary.
Do you think there is a chance we can merge this in the nearest future, or does taking a step back to solve it in a concise way across strategies require this PR to be put on hold?
(I will work on fixing the tests if you say we can continue with this.)
@kiview Would you be able to provide additional feedback on how this PR can proceed? With more and more folks using something other than Docker Desktop this would be a very nice quality of life improvement.
Also - since at least one other implementation (.NET) supports this exact same config it would be a step towards consistency there as well. The golang implementation supports configuring it in the properties file too.
Thanks!
@jordanjennings we are working on a PoC for testcontainers-go, in which we want to proceed supporting reading the docker socket from the current docker context. If any container runtime provides a docker context, and this context is activated, then testcontainers libs will work OOTB, with no extra configuration.
You can take a look at how it looks like in the Go implementation here: https://github.com/testcontainers/testcontainers-go/pull/2810