-
-
Notifications
You must be signed in to change notification settings - Fork 511
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
chore: resolve IPv4-IPv6 issues #2403
chore: resolve IPv4-IPv6 issues #2403
Conversation
It will avoid random ports to be retrieved, so that the wait strategy does not choose the wrong port
✅ Deploy Preview for testcontainers-go ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
* main: chore(deps): Bumping ChromaGo client version (testcontainers#2402) chore(deps): bump github.com/docker/docker from 25.0.3+incompatible to 25.0.5+incompatible (testcontainers#2444)
@cristianrgreco I ping you as you already implemented this for NodeJS, and I used it as reference. Could you please take a look? 🙏 |
Relates moby/moby#47871 |
* main: chore: print Docker Info labels in banner (testcontainers#2681) fix: incorrect parsing of exposedPorts in readiness check (testcontainers#2658) feat: add grafana-lgtm module (testcontainers#2660) Added valkey module (testcontainers#2639) fix: container.Endpoint and wait.FortHTTP to use lowest internal port (testcontainers#2641)
Closing here, because resolved in the Moby upstream at moby/moby#47871. |
What does this PR do?
It looks up the bounded ports every time a container needs to get a mapped port. It also improves the wait strategies (http and host-port) to get the bound port.
To get the bound port, we'll get the host IP addresses from the current Docker Host, and with that list of values, and the ports from a container, we will get the bound ports.
Finally, we are deprecating the
ForceIPv4LocalHost
field from the HTTPStrategy, as it's not needed anymore. The example test is updated to fix the port in the wait strategy.Why is it important?
Resolves flakiness in the CI, as the testable example is failing in a non consistent manner: because the test exposes two ports, 8080 and 80, the way Docker is retrieving them from the JSON representation is not deterministic (it's a port map), therefore, the test is sometimes returning the 80 port for getting the HTTP endpoint and others, the 8080 port.
At the same time, it adds a more consistent manner of getting the host and the port, relying on the Docker host, taking into consideration the IPv4 and IPv6 families.
Related issues