Currently, when bringing up Docker containers for developers, we give MySQL a good amount of time on first start to find out when it is "healthy"; that is to say, when it has finished its first-run procedures and is listening for connections. Once the container becomes healthy, we run our Flyway migrations, mitigating the issue that was brought up in #357 for Flyway migrations not running on machines that were too slow to start MySQL before Flyway timed out.
However, under certain circumstances, we're still not giving enough time to determine if MySQL started healthily or not, so the MySQL container is marked as unhealthy and the Flyway migrations are still not run.
Expected Behaviour
The expectation is that, no matter what machine is running it, running docker compose down and then docker compose up will bring up the same development environment every time on every machine.
Actual Behaviour
For machines that can't start MySQL fast enough, running docker compose down then docker compose up may cause the Flyway migrations not to run and lead to a broken development environment.
Steps to Reproduce
Grab a dual-core Windows 10 machine with limited RAM and configure it for use like a normal user would.
Set it up for development, running our environment within WSL2, even optimizing it so Docker runs in the same WSL2 environment and not a separate one.
Try to bring up our images with docker compose up and observe that it's only sometimes able to do so, enhanced if the containers are started one-by-one or if you've already attempted once to start them.
Additional Details and Resources
The ideal fix would be to increase the number of tries it takes in the docker-compose.yml file to start MySQL before it marks it as unhealthy. However, I'd also like to take this opportunity to address the delay in running the Flyway migrations too and increase the frequency with which the MySQL container is checked to see if it's healthy.
Correct Project Selected
[X] This issue is linked to the appropriate project
Describe the Bug
Currently, when bringing up Docker containers for developers, we give MySQL a good amount of time on first start to find out when it is "healthy"; that is to say, when it has finished its first-run procedures and is listening for connections. Once the container becomes healthy, we run our Flyway migrations, mitigating the issue that was brought up in #357 for Flyway migrations not running on machines that were too slow to start MySQL before Flyway timed out.
However, under certain circumstances, we're still not giving enough time to determine if MySQL started healthily or not, so the MySQL container is marked as unhealthy and the Flyway migrations are still not run.
Expected Behaviour
The expectation is that, no matter what machine is running it, running
docker compose downand thendocker compose upwill bring up the same development environment every time on every machine.Actual Behaviour
For machines that can't start MySQL fast enough, running
docker compose downthendocker compose upmay cause the Flyway migrations not to run and lead to a broken development environment.Steps to Reproduce
docker compose upand observe that it's only sometimes able to do so, enhanced if the containers are started one-by-one or if you've already attempted once to start them.Additional Details and Resources
The ideal fix would be to increase the number of tries it takes in the
docker-compose.ymlfile to start MySQL before it marks it as unhealthy. However, I'd also like to take this opportunity to address the delay in running the Flyway migrations too and increase the frequency with which the MySQL container is checked to see if it's healthy.Correct Project Selected
Labels