metabase / metabase-qa

Make Metabase More Awesome

Metabase QA

This repository contains:

• Docker images with pre-populated data for integration testing

Database Configurations

As part of standard QA process, we test different types of database setups:

• Single schema, single user access
• Multi schema, single user access
• Multi schema, multi user access

What this looks like in practice, is we have the following configurations:

• Metabase Sample Database with a single metabase user
• Metabase Sample Database + second schema with other random sample data
• Custom sample data that may or may not be database dependent
  • e.g. Postgres JSON types

Using in Testing

Use Docker images of the form: metabase/qa-databases:{DATABASE}-{QA_TYPE}-{VERSION}

Currently the only supported databases are mongo, postgres and mysql and the only supported "QA type" is sample.

Supported database versions have their own Dockerfile in each directory.

We use a standard set of database names and users for our sample images:

• Database name: sample
• Username: metabase
• Password: metasample123

Listed below are the examples for running each of the supported databases in Docker.

Mongo 4

docker run --rm -p 27017:27017 --name meta-mongo4-sample metabase/qa-databases:mongo-sample-4.0

PostgreSQL 12

docker run --rm -p 5432:5432 --name meta-postgres12-sample metabase/qa-databases:postgres-sample-12

MySQL 8

docker run --rm -p 3306:3306 --name meta-mysql8-sample metabase/qa-databases:mysql-sample-8

Supported Databases and Versions

These images are currently pushed to the public metabase/qa-databases repository:

• metabase/qa-databases:mongo-sample-4.0
• metabase/qa-databases:mysql-sample-5.7
• metabase/qa-databases:mysql-sample-8
• metabase/qa-databases:postgres-sample-11
• metabase/qa-databases:postgres-sample-12

Building

Building is manual for now until we support more databases.

Sample Data

For Postgres, sample_data.sql.gz contains the Metabase Sample Database. For Mongo, we extract the sample data from Postgres into files that are then loaded with mongoimport.

Building/Updating Images

To build either the mongo or postgres images, change into the respective directory and execute the build.sh script.

cd dbs/postgres
./build.sh

WARNING: This currently also tries to push the image to Docker Hub, so if you don't have access that part will fail.

If the Sample Database has changed in Postgres, you can run ./update_data.sh in dbs/mongo to update the data files.

References

• Saving a Postgres Database in a Docker Image
• eksctl has a good example of committing an intermediate image.
• A couple other good Docker/Makefile tooling examples

metabase-qa's Issues

More database images

We should have as many database images as we support (unfortunately there are many commercial ones or even SaaS ones). We could have (based on the current containerized environments):

• druid (https://druid.apache.org/docs/latest/tutorials/docker.html)
• ms sql (https://hub.docker.com/_/microsoft-mssql-server)
  - sqlite (a file inside the MB container or even a simple alpine image with a db inside)
• spark (https://hub.docker.com/r/bitnami/spark/)
• trino, formerly presto (https://hub.docker.com/r/trinodb/trino/)

"build.sh: 11: [[: not found" when running script

The script errors here:

metabase-qa/dbs/mongo/build.sh

Line 11 in d540194

if [[ $version == 4* ]]; then

Build images in Github Actions

In our current situation, we build images manually and push them from our devices. We should build this images in GHA and push them automatically to Dockerhub

Make images multiarch

Our current images are only available for x86, we should build and push multi-arch for when we make Metabase multi-arch as well

Weekly builds of the latest emails where available

We should only build the images of the first version we support of each database and after that, a weekly build of the :latest tag of every database we support. In that way we could automatically know if something breaks

Dockerfiles have many intermediate images

We should have one liners for environment variables or copy commands to reduce the intermediate containers that are being built