Yesterday, I was running into an issue while trying to register a new GitLab CI Runner with our self-hosted GitLab instance. While that worked fine about 2 weeks ago, it did not this time. The only difference is, that we recently upgraded to version 15.9.2 of GitLab.
We've covered the basics of our Docusaurus CI setup already in another blog post. In this blog post, we'll show you how to the build pipeline to lint the nginx configuration used in our Docusaurus setup.
Recently, I wanted to improve our CI build pipelines with some custom-built Docker images for our PHP projects. To make sure I can reuse the image in as many of our projects as possible, I wanted to compile and install as many PHP extensions as possible.
It's been a few months sine we migrated from Silverstripe to Docusaurus for our blog. Quite a few blog posts have been published since then via the CI pipeline we've set up. This blog post covers how we do things.
For a client, we also handle the vulnerability management of the projects. This also involves manual checks after a new project is launched, to ensure that no critical security problem is caused by misconfiguration.
Testing GitLab CI build pipelines can be a bit annoying. You must make your changes, commit and push them to kick off the CI pipeline. Then you have to wait a while for the result to show up and start over again if something went wrong. If your CI runners are busy, you keep waiting and waiting for the next free slot. Luckily, it is possible to run GitLab CI jobs completely locally. After installing the gitlab-runner package locally, you can execute a job like this:
Recently we hit a problem in our Force Login Magento 2 module: The module was not compatible anymore with Magento 2.1 due to a change in a constructor of a Magento base class we extended. This broke the DI configuration which in turn meant the module was not installable in a Magento 2.1 project any more. We were not able to spot this problem early on as our Travis build did only run against the latest Magento version 2.2. Inspired by this blog post of the heidelpay developers, I began to restructure our Travis build.
In my recent attempt to migrate away from our Jenkins infrastructure to the new GitLab CI Runner infrastructure I ran into a problem: Since we want to use Docker images for the GitLab CI builds I struggled a bit on how pass the authentication information for Satis and GitLab into the docker images. Since the base images - basic PHP setup - should be used for our projects I did not want to share the access credentials in the different base images. Gitlab's secret variables sounded like a good idea but unfortunately they need to be defined for each and every project. Currently we have more than 250 projects in our GitLab instance, configuring secret variables for all the projects would have been a big pain.
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.