If running from a container host-network-mode test fail because we cannot connect to host network. This prevents the cleanup.
So make sure we always return network for later removal.
Explicitly return None for readability
-Improve the DockerComposer contextmanager to make sure teardown happens by using try except block.
-Move the self. declarations up so we are sure they are set even if an exception occurs.
-set self._networks
Debian bookworm (current stable) still has python3-docker 5.0.3. The
reverted commit prevented the test-suite to run natively on this distro.
The version check could be bumped again when the next Debian stable (trixie)
will be released (by fall 2025 hopefully).
Enable overriding default 'docker compose' command with environment variable
'DOCKER_COMPOSE'. This way docker compose v1 is still supported with:
$ DOCKER_COMPOSE=docker-compose pytest
This is important because people using the Debian packaged docker compose
are stuck to v1.
This makes it possible to bring up different compose files for
different tests in the same test module.
This change does not negatively affect performance because the fixture
is a no-op if the docker compose filename is unchanged between tests.
A test on raw IP addresses doesn't reach the existing IPv6 skip logic, added that to avoid a test failing when only IPv4 is available (eg: standard docker container networks).
Additionally some other tests set the `none` network and connecting to this fails as it's not allowed? Preventing that from happening resolves the final failing tests within containerized pytest.
The `network` object would never be in a list of network names (strings), and without `greedy=True` arg as the `docker-py` API docs note, the containers will not be part of the results, thus always returning an empty list which was not intended..
Now the network will properly match the current networks for pytest container, avoiding duplicate connect attempts, and the network list result will actually have containers to count when filtering by length.
When the container runs with host networking instead of the default bridge, the `$HOSTNAME` / `/etc/hostname` reflects that of the host instead of the container ID , which causes the pytest container to get removed accidentally.
Using a container name instead we can more reliably target the container to avoid removing it, should we need to run with host networking instead.
The original `/.dockerenv` approach is no longer valid, and context wise we're only using this for the test suite, so using an ENV in that container is a better solution.
