Add a database to a machine executor

Build Environment
1

I’ve been working with docker executors for a little while, but I barely understand how any of this works. This is a snippet of my circleci config.yml file that worked last summer to perform visual regression testing on a drupal web site, before a version bump threw everything off, and I stopped being able to get any part of the circleci config to work:

 defaults: &defaults
   docker:
     - image: rhodeswebdev/cci-drupal-percy:v0.17
       environment:
         XDEBUG_MODE: coverage
     - image: mariadb:10.4
       environment:
         MYSQL_ALLOW_EMPTY_PASSWORD: 1

I finally got around to recreating the visual regression testing system, but for some reason composer fails to run for me now inside this docker image, locally or in the circleci system. It works on my local macbook pro; it works on our staging and production systems (composer install runs on the remote server every time I push changes); and via circleci email support, I’ve found that composer will run on a machine executor. But, I can’t figure out how to add a database image alongside the machine executor. In the process of creating this topic, I found this: Creating database for macos executor – which almost sounds like using a machine executor is basically the same as running a VPS; is that correct? Do I just use apt to install mariadb? That seems extremely inefficient.

In the snippet above, I was in the process of creating my own docker image that would have everything i needed (php, node, percy/api) pre-installed before trying to spin up a circleci environment to run the tests. That makes sense, but it does not make sense to use a Machine Executor if I have to install and configure MariaDB every time I run tests.

2

It is hard to comment on your config unless you can post more of it and the error you are seeing. The first thing to check if things are not working is the size of your resource class - do you have enough ram?

As for the database issue, this is a common issue for any CI system that is not persistent. Some of the options are

  • Host the database on another persistent environment somewhere on the internet. Unless you are testing for response time-based issues this only really adds the cost of hosting the DB.

  • Look at a self-hosted runner. This would allow a persistent database to be deployed on the runner.

  • If you have static data in your database that is used every run you could create a dedicated docker image with the database included.

  • If the data is dynamic in nature you could create a database container that pulls the database files from git at runtime.

As the solution becomes more dynamic it is worth looking at ‘Remote Docker’ support as you can better control the environment that is deployed.

If you have not already found it the starting docs can be found here.