-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(core): running testcontainer inside container #714
fix(core): running testcontainer inside container #714
Conversation
bcfb770
to
51ec378
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #714 +/- ##
=======================================
Coverage ? 85.62%
=======================================
Files ? 12
Lines ? 654
Branches ? 102
=======================================
Hits ? 560
Misses ? 72
Partials ? 22 ☔ View full report in Codecov by Sentry. |
53f8d09
to
e0d969e
Compare
also use utils for platform detection
see testcontainers#475 (comment) for a summary
d80b3b1
to
341bd03
Compare
required to finally figure out how github actions actually work
341bd03
to
9f4d1ba
Compare
I am happy to announce that I was able to add some DinD and DooD directly into the test suite that work even within the github action here. I think this is a good starting point to tackle more issues arising from running testonctainer within a container itself. Following the discussion with @alexanderankin on #720 I am aware that testing non core thing inside the core test is not really wanted. |
def pytest_configure(config: pytest.Config) -> None: | ||
""" | ||
Add configuration for custom pytest markers. | ||
""" | ||
config.addinivalue_line( | ||
"markers", | ||
"inside_docker_check: test used to validate DinD/DooD are working as expected", | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this just for filtering in/out dind/dod tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is to filter out tests that run within the test_dind
and test_dood
tests.
Inside this tests now the docker container is build and executed in a dind
and dood
environment.
This way we have proper test that dind
and dood
actually works.
I left the old make test-dind
(which is not correct because it's acutall DooD) untouched.
It would actually be better to remove it not only because of the wrong name.
It also doesn't succeed because some things as some auth tests seem to have troubles with TLS settings.
I don't think the complete test suit has to pass inside a dind/dood env.
In the end these test are integration tests and should be treated as such.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lets remove the things that don't make sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps in a separate PR maybe to make the history clearer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great! I still have a couple things I want to figure out before merging because its a lot. in particular I don't like the breaking change with the returning int instead of string because if I'm not mixing it up there is a method somewhere in there that returns str but actually returns int or str but i dont want to do that without a version bump (4.9 or just v5).
To be frank, that doesn't matter as all, as long the packages is not marked as typed (#305), it is not considered by type checkers from end users anyway. |
def get_container_host_ip(self) -> str: | ||
# infer from docker host | ||
host = self.get_docker_client().host() | ||
if not host: | ||
return "localhost" | ||
# see https://github.com/testcontainers/testcontainers-python/issues/415 | ||
if host == "localnpipe" and system() == "Windows": | ||
return "localhost" | ||
|
||
# # check testcontainers itself runs inside docker container | ||
# if inside_container() and not os.getenv("DOCKER_HOST") and not host.startswith("http://"): | ||
# # If newly spawned container's gateway IP address from the docker | ||
# # "bridge" network is equal to detected host address, we should use | ||
# # container IP address, otherwise fall back to detected host | ||
# # address. Even it's inside container, we need to double check, | ||
# # because docker host might be set to docker:dind, usually in CI/CD environment | ||
# gateway_ip = self.get_docker_client().gateway_ip(self._container.id) | ||
|
||
# if gateway_ip == host: | ||
# return self.get_docker_client().bridge_ip(self._container.id) | ||
# return gateway_ip | ||
return host | ||
connection_mode: ConnectionMode | ||
connection_mode = self.get_docker_client().get_connection_mode() | ||
if connection_mode == ConnectionMode.docker_host: | ||
return self.get_docker_client().host() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw: one could argue that this is incorrect.
self.get_docker_client().host()
does return a DNS name instead of an IP especially localhost
.
Indeed for some containers this has a negative effect: I tried to create a MariaDB container that failed. Using localhost
instead of 127.0.0.1
it was trying to connect through the unix socket.
But this is the old behaviour so I kept it the way it is.
We might want to change this in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah yes, as it says "container_ip" in the method name but it returns a domain name instead, hm.
they both have been replaced by proper `pytest` tests follow up of #714
closes #475
One step closer to solve #517
Replaces #622
According to the data collected this should fix issues running testcontainers inside a container in almost all cases.
There is still an issue when running it within docker desktop, that is probably easily solved which checking for the existence of
host.docker.internal
.But I have to recollect the data to ensure this, so this will be added at later point in time, as with with setting
-e TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal
an easy workaround exists as well.