Can not access the api from Localhost in the Github actions workflow

I created a Spring sample, and tried to build the application into a Docker image and run the application in Docker container and perform a simple Smoke test to make sure the image is created as expected.

The Docker image is created by the Spring boot maven plugin.

I created a simple docker-compose file to run the application and database together.

version: "3.5" # specify docker-compose version, v3.5 is compatible with docker 17.12.0+

# Define the services/containers to be run
    image: mysql:8
      - "3306:3306"
 #   command: --default-authentication-plugin=mysql_native_password  
      MYSQL_ROOT_PASSWORD: mysecret
      MYSQL_USER: user
      MYSQL_PASSWORD: password
      MYSQL_DATABASE: testdb
      - ./data/mysql:/var/lib/mysql    
      - ./mysql-initdb.d:/docker-entrypoint-initdb.d
    image: hantsy/rest-many-to-many-example
      - db
      - "8080:8080"
      - "SPRING_DATASOURCE_URL=jdbc:mysql://db:3306/testdb"

In the Github actions workflow, it does not work, a Java test(or using curl command) failed to connect to http://localhost:8080 in the same flow.

The Github actions workflow file is here.

But it worked well on my local machine, accessing http://localhost:8080 is working as expected.

The compose file looks like it should work.

It’s hard to be sure without logs, but one common issue with automated workflows is speed: If the next step sends test request, it’ll likely be a lot faster than you can manually start tests, and if the server needs a moment to start, it might not be ready by then. In that case you need to wait for the server to start. The best way to do that depends on your system, but one approach that works for (almost) everything is to probe the port in a loop with a short sleep between tries, and a timeout.

Either way, adding docker-compose logs to your workflow might be useful to gather more information on what’s happening.

I have added a sleep before running the test.
I attached the link of the Github actions workflow file in the original post.

The command in your workflow is curl, not curl http://localhost:8080/report. Drop the haythem/public-ip action from the workflow and just use localhost as the target for tests, that’s what the port mapping is for.

Originally I used localhost, it did not work, so I tried the public IP instead.

Localhost is definitely correct, though, assuming the port itself works. :slightly_smiling_face:

I looked at the workflow log here. The docker ps just before you retrieve the logs says the container has been up for less than a second, which is way shorter than the Spring containers I’ve seen needed to start.

I’m not seeing anything in the log that’d wait for the container, maybe whatever you added to wait isn’t working right?

I moved the wait-for-it script out of the docker-compose YAML file. And add a hard code to sleep beween db and app startup, it worked now.

See: spring-puzzles/rest-many-to-many.yml at de29c9d53296d0054cb0b0468e23c36d0d5e0563 · hantsy/spring-puzzles · GitHub

1 Like

I think the wait-for script is not enough to detect the readiness of the databases, when the server port is up in the startup stage, the database instance is not ready for connections.

Maybe have to write a SQL select query to ping the target database to makesure it is ready.

1 Like