In order to ensure that MariaDB runs smoothly, it needs to be tested on multiple platforms and configurations. In order to obtain a gain both in terms of speed and flexibility, we have decided to use Docker latent workers. In this way, each different environment is defined in a separate dockerfile. Besides having a clean and concise environment definition, using latent workers has the advantage of requiring minimal configurations on the worker machines. This makes the process of adding new hardware very easy, mainly involving installing Docker and configuring Docker remote access.

Now that we have the build environments defined, we can start testing. The process starts by cloning the MariaDB server repo and creating a source tarball. Then, all other configurations are triggered, all using the same source tarball.

While it seemed quite straightforward, the whole process turned out to be more challenging than we expected. This includes a quite long list of issues ranging from files mixups, weird sporadic failures where the main testing process was killed, grid view customizations to multi-master configuration and master-worker file transfer problems. In this talk, I will talk in more detail about these issues and tell you more about our experience and how we managed to overcome them.