I am facing an issue that I'm not able to figure out. What I want to achieve is to have a gradle task that spawn a docker-compose process that is a mssql server, and then use liquibase to run-up all migrations and seed the database.
But the problem is that the docker takes some time to get the server up, and the liquibase is running before it gets up.
What i did was to start docker-compose in a daemon using -d flag, and then use a loop to ping the server until the port 1433 responds and then let the gradle continue with the other dependent tasks (that actually creates the database and seed it).
here is what I did:
task checkDbStatusAndGetsItUp(){
group "localEnvironment"
description "Check current local db is up or sets it up"
dependsOn 'cloneEntityProject'
println 'Checking db Status and setting it up'
println '---------------------------'
def stdoutDocker = new ByteArrayOutputStream()
exec{
executable 'sh'
args "-c", """
docker ps | grep microsoft | wc -c
"""
standardOutput = stdoutDocker
}
doLast {
if (stdoutDocker.toString().trim() == '0') {
exec {
executable 'sh'
workingDir 'setup/dp-entidades'
args "-c", """
docker-compose up -d
"""
}
}
def shouldStop = false;
while (shouldStop == false){
def stdoutPing = new ByteArrayOutputStream()
exec{
workingDir 'setup/dp-entidades'
executable 'sh'
args """
nc -zv localhost 1433
"""
ignoreExitValue = true
standardOutput = stdoutPing
}
println stdoutPing.toString();
sleep(1000)
}
}
}
What I get from the above code is a loop showing that the docker never gets it up. But if I open another terminal and ping it manually it works, and the database is actually up. (I even tried to use telnet, with same results)
What I need to do, to achive the ping from the gradle and if success on conecting to database let the task continue?
-c
flag of sh
is missing in the last exec
block. Another problem is that you never set shouldStop
to true, so the last loop will never terminate. You can e.g. check the exit status of exec
:
def result = exec { ... }
shouldStop = result.exitValue == 0
Note that you should also limit the number of tries to propagate server failure instead of waiting forever.