I’m having trouble with a workflow automation tool in our CI/CD setup. It works fine on our local machines but fails in the GitHub Actions environment. The error message suggests a connection problem:
ConnectionError: HTTPConnectionPool(host='localhost', port=1234): Max retries exceeded with url: /api/v1/credentials (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f3d28e3d810>': Failed to establish a new connection: [Errno 111] Connection refused'))
Our Docker setup includes the following for the problematic service:
workflow_tool:
image: example.com/workflow-automation:latest
ports:
- '1234:1234'
environment:
- TOOL_HOST=workflow_tool:1234
- TOOL_PORT=1234
- TOOL_PROTOCOL=http
- NODE_ENV=production
- DB_TYPE=postgres
- DB_TABLE_PREFIX=wf_
- DB_POSTGRES_DATABASE=workflow
volumes:
- ./config/data:/home/user/.config
- ./config/files:/files
We’re trying to access this service from our FastAPI app using Python’s requests library. What could be causing this difference between local and CI environments? The Docker setup is identical, and we reset environment variables in our test script.
I’ve narrowed down the issue to these curl commands:
curl --fail http://localhost:8080 || exit 1
curl --fail http://localhost:1234/api/v1/docs/ || exit 1
The first command works, but the second fails with ‘Connection refused’. I’ve tried different ports, but the issue persists. Any ideas on what might be causing this in the GitHub Actions environment?
The issue you’re experiencing is likely due to networking differences between your local environment and GitHub Actions. In CI/CD pipelines, services often can’t communicate via ‘localhost’ as they would on a single machine.
Try modifying your Docker Compose file to use ‘host.docker.internal’ instead of ‘localhost’ for inter-container communication. This allows containers to refer to the host machine’s network.
Also, ensure your GitHub Actions workflow is configured to run the Docker Compose setup correctly. You might need to add a step to wait for the workflow tool service to be fully up before running tests.
If these don’t work, consider using Docker’s internal networking. Define a custom network in your Docker Compose file and use the service name as the hostname instead of ‘localhost’.
Lastly, double-check that the workflow tool’s port is exposed correctly in your GitHub Actions environment. Sometimes, additional configuration is needed to make ports accessible in CI/CD environments.
I’ve dealt with similar issues in my CI/CD pipelines before. One thing that often gets overlooked is the networking setup in GitHub Actions. Unlike your local environment, Actions runs each step in isolation, which can cause connectivity problems between services.
Here’s what worked for me: Instead of using ‘localhost’ or even ‘host.docker.internal’, try using the actual service name as defined in your Docker Compose file. In your case, that would be ‘workflow_tool’.
Also, make sure your GitHub Actions workflow is setting up the Docker network correctly. You might need to add a step to create a custom network and attach your containers to it.
Another thing to check is the timing. Sometimes, the workflow tool might not be fully initialized when your tests start running. Adding a small delay or a health check before running your tests can help ensure everything’s up and running.
Lastly, double-check your GitHub Actions logs. Sometimes, there are subtle differences in how environment variables are set up compared to your local machine, which can cause unexpected behavior.
Have u tried using the service name instead of localhost? In docker networks, containers can communicate using their service names. Change ur FastAPI app to use ‘workflow_tool’ as the hostname instead of ‘localhost’. this might solve the connection issue in github actions environment.