Best way to make our automation script wait until the database has been imported before proceeding to next step

You are viewing an old version of this question. View the current version here.

We have automation in our pipelines that spins up a MariaDB container and then runs several tests again the application.

We have a docker-compose.yml file that includes something like this

``` services:

db: image: mariadb:10.6.15 ports: - "3306:3306" env_file: compose/env/db.env volumes: - dbdata:/var/lib/mysql - ./compose/files/db/:/docker-entrypoint-initdb.d/

volumes: dbdata: ```

As part of the automation process we have a `.sql.gz` file that is placed in the ./compose/files/db directory.

Our automation scripts are essentially doing

``` docker-compose up -d

  1. Now run some tests, that require the sql file to have been imported. ```

We have historically hardcoded a `sleep` statement, but this doesn't feel like the most accurate.

Is there a way we could have the `docker-compose up` command no complete until the `.sql` file is imported, or is there another recommendation for how we can have our automation wait until the db has been imported?

We are discussing some hacky workarounds like polling the DB for the presence of some data, but it feels like there should be a better way

Answer

Like using-healthcheck-sh.

The initialization from /docker-entrypoint-initdb.d occurs while mariadbd is running under --skip-networking, so will return healthy once its finished.

Use https://docs.docker.com/compose/compose-file/05-services/#healthcheck (and the meanings on https://docs.docker.com/reference/dockerfile/#healthcheck).

The start_period covers the estimated startup time.

Then for the services depending on mariadb (service name):

    depends_on:
      mariadb:
        condition: service_healthy

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.