Description
This is probably the same issue as #26 but I'm not 100% sure so I'm opening a separate issue.
I'm trying to set up the test suite for my application (Skosmos) which needs to access a Jena Fuseki triple store (RDF database). I've set it up as a service container, just like @shamotj has done with PostgreSQL. But I can't access it from the PHPUnit tests if I use php-actions/phpunit. The reason seems to be that the container where the PHPUnit tests are executed is not in the same (virtual) network as the service container. The service container I use is configured like this:
services:
fuseki:
image: stain/jena-fusekiand the command that starts it up (automatically generated by the GitHub Actions environment) looks like this:
/usr/bin/docker create --name f6520557790c4e89b09c97b14c9fc9e7_stainjenafuseki_8e86dc --label 8a33c1 --network github_network_b6654ecefeeb43dba0ad25d5aad81a77 --network-alias fuseki -e GITHUB_ACTIONS=true -e CI=true stain/jena-fuseki
The important parameter here is --network github_network_b6654ecefeeb43dba0ad25d5aad81a77, which specifies a network for the service container. In addition, --network-alias fuseki creates a name that refers to this container, so it now becomes accessible as the hostname fuseki from other containers attached to the same network.
But the command for starting the PHPUnit container looks like this:
docker run --rm \
--volume "${github_action_path}/phpunit.phar":/usr/local/bin/phpunit \
--volume "${GITHUB_WORKSPACE}":/app \
--workdir /app \
--env-file <( env| cut -f1 -d= ) \
${docker_tag} "${command_string[@]}"Note that there is no --network parameter, so this container will be attached to the default bridge network, not the specific network where the Fuseki service container is. So it is in effect isolated from the rest of the system and cannot access any network services in the same CI environment. Consequently, my PHPUnit tests are failing with this error:
Unable to connect to fuseki:3030 (php_network_getaddresses: getaddrinfo failed: Name does not resolve)
I think that the fix would be to add a --network parameter to the docker run command with the correct network ID; in my example, it was github_network_b6654ecefeeb43dba0ad25d5aad81a77. Unfortunately I'm not sure how to construct this network ID; it doesn't appear among the default environment variables set by GitHub Actions but it's possible that it could be constructed based on them.
Alternatively, the parameter could be set to --network host and then the PHPUnit container would not be in its own isolated network. Then the service containers could be exported to the host using the normal ports mapping mechanism and they should be accessible to the PHPUnit tests.