I wasn't really happy with the current approaches of dealing with different Dockerfiles and docker-compose.yaml files for development and production containers. I don't really see the point of managing multiple configuration files, building a few intermediate containers when the only difference between a development image and a production image is that the code is copied into the image during build. Adding files on every build is also not an ideal solution as you could potentially ship an old version of the application when you miss running a docker build after you made your final changes.
We recently started experimenting with the GitLab CI Runners as we are looking to replace our "old" Jenkins v1.x set up with something new. And since over the last few weeks we had some issues with the Jenkins GitLab plugin we thought it might a good idea to take a deeper look into the GitLab CI Runners. One the plus side the GitLab CI Runners are configured via a YAML file in a similar fashion as you would configure Travis CI which we use to build our open-source components. Since on Travis we rely a lot on the so-called matrix builds to run the unit tests for different PHP versions I was wondering how we could solve the problem with GitLab CI. At first glance GitLab CI does not have a matrix build command but it comes with a feature called Anchors which kind of act as a template that can be merged in a job configuration.