Open eddumelendez opened 8 months ago
Is the properties-ruby
gem overkill here? Maybe a TESTCONTAINERS_HOST
env variable could serve the same purpose without adding a new dependency. 🙂
The properties-ruby
gem also seems really old and unmaintained which could cause problems in the future!
I think we should support both TESTCONTAINERS_HOST
and ~/.testcontainers.properties
but I agree with @HeyNonster in the concerns about the properties-ruby
gem, I'll implement the .properties
reader manually in Utils class keeping the same API of properties-ruby
.
I'll implement the .properties reader manually in Utils class keeping the same API of properties-ruby
Great! @guilleiguaran LMK once it is available and I can rework the PR.
I think we should support both TESTCONTAINERS_HOST and ~/.testcontainers.properties
TESTCONTAINERS_HOST
is not an env var in the libraries but there are others to make other Container Runtimes work with Testcontainers.
TESTCONTAINERS_HOST
is not an env var in the libraries but there are others to make other Container Runtimes work with Testcontainers.
While not currently an env var, I think it would be useful to be able to use it. For example, instead of:
tc_host = properties.get(:"tc.host")
We could have:
tc_host = ENV["TESTCONTAINERS_HOST"] || properties.get(:"tc.host")
Or swap the order of the two depending on which value you'd like to take precedence. Let me know what you think! :)
Thanks for the feedback and sorry for not providing the context when submitting the PR.
The support for tc.host
is a specific integration mechanism with Testcontainers Desktop and Testcontainers Cloud (although in theory, other providers could integrate through the same way). In order to ensure a consistent experience with other languages when integrating with Testcontainers Cloud and Testcontainers Desktop, tc.host
should not be resolved through an ENV variable, but only be read from .testcontainers.properties
in the user home dir (where the application update the value accordingly).
I think what is related to the goal of the discussion here, is supporting DOCKER_HOST
as an environment variable, which is idiomatic with other Testcontainers languages as a more generic way of configuring the Docker host.
Hi @guilleiguaran, any update to support reading properties files?