Open 0x442E472E opened 11 months ago
Have you checked Startup Check Strategies? Testcontainers has a lot of examples using those without exposed ports being declared.
@eddumelendez yes i did, but those are unrelated to my point and the Exception occours before the Startup Check Strategies play a role. Let's take the PostgreSQLContainer as an example and an integration test to test some app with a real Postgres database. When running the test locally on a dev laptop right from the IDE, one might need to expose port 5432 (directly or mapped) so the app can access the database. PostgreSQLContainer exposes that port by default. This same test will not work in a CI environment, where the container runtime does not need exposed ports. I think Testcontainers should abstract from those network specifics so the user does not have to write two flavours of his test, one with exposed ports and one without.
Module
Core
Testcontainers version
1.19.2
Using the latest Testcontainers version?
Yes
Host OS
Linux
Host Arch
x86
Docker version
What happened?
There are cases where no exposed or mapped ports are required. A common case being the network mode "host". For me it's happening when i run rootless Podman in a sidecar container using the Gitlab CI Kubernetes Executor, but here seems to be a ticket where Jenkins and Docker is used: https://github.com/testcontainers/testcontainers-java/issues/7903
In those cases, starting a container with exposed ports will fail, because the container runtime will not actually expose or map any ports. However, testcontainers-java requires the ports to be mapped. This happens without specifying a network mode, so it's not related to this issue: https://github.com/testcontainers/testcontainers-java/issues/5151
A workaround for this problem is to remove any exposed ports. However, this workaround has major disadvantages:
Relevant log output
Additional Information
No response