github workflow: "ECONNREFUSED 127.0.0.1:***" error when connecting to docker container

Question

In my github actions workflow I am getting this error (ECONNREFUSED) while running my jest test script. The test uses axios to connect to my api which is running in a container bootstrapped via docker-compose (created during the github workflow itself). That network has just has 2 containers: the api, and postgres. So my test script is, I am assume, on the "host network" (github workflow), but it couldn't reach the docker network via the containers' mapped ports.

• I then skipped jest test entirely and just tried to directly ping the containers. Didn't work.
• I then modified the workflow to inspect the default docker network that should have been created:

UPDATE 1

I've narrowed down the issue as follows. When I modified the compose file to rely on the default network (i no longer have a networks: in my compose file):

So it looks as though the containers were never attached to the default bridge network.

UPDATE 2

It looks like I just have the wrong paradigm. After reading this: https://help.github.com/en/actions/configuring-and-managing-workflows/about-service-containers I realise this is not how GA expects us to instantiate containers at all. Looks like I should be using services: nodes inside the workflow file, not using containers from my own docker-compose files. 🤔 Gonna try that...

Answer 1

So the answer is:

1. do not use docker-compose to build your own custom containers. GA does not support this yet.
2. Use services: in your workflow .yml file to launch your containers, which must be public docker images. If your container is based on a private image or custom dockerfile, it's not supported yet by GA.

So instead of "docker-compose up" to bootstrap postgres + my api for integration testing, I had to:

1. Create postgres as a service container in my github workflow .yml
2. Change my test command in package.json to:
   • first start the api as background process (because I can't create my own docker image from it 🙄) then
   • invoke my test framework next (as the foreground process)

so npm run start & npm run <test launch cmds>. This worked.