How to Test Gitlab CI Pipelines locally in 2025
Three years ago I wrote a post about how to test GitLab CI pipelines locally. Unfortunately, GitLab discontinued this feature some time back as part of the Runner application's refactoring process.
Three years ago I wrote a post about how to test GitLab CI pipelines locally. Unfortunately, GitLab discontinued this feature some time back as part of the Runner application's refactoring process.
To have the most flexibility for our CI pipelines, we use the Docker runner in our GitLab CI environment. This allows us to easily customize each job in each build pipeline for each of our customers, ensuring they match our specific needs.
We've been using a self-hosted GitLab instance for our customer projects since the end of 2015. We immediately jumped on GitLab CI when it was first released to replace our old Jenkins infrastructure with a more modern pipeline-as-code approach.
FrankenPHP can embed the source code and assets of PHP applications in a static, self-contained binary. This, paired with GitLab CI, streamlines deployments and releases.
While setting up a GitLab CI build & deployment pipeline for one of our customer projects, I had the need to expose GitLab's environment-specific variables in multiple jobs as I needed the information in the build & deployment steps. Since I needed to run the jobs on different servers, I was not able to combine both jobs.
In a few projects, we sometimes had the problem, that invalid JSON files were provided by the customer and not checked for errors. To prevent this, we searched for the smallest possible solution.
Recently, we've been running into a weird problem. After restarting 2 nodes in our Nomad cluster, we could not properly access GitLab via SSH anymore. Web access was working fine, also cloning via https:// worked, but not via SSH which is what most of our developers use by default.
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.
There are cases where I do not want to clone a complete project just to make a small change. GitHub and GitLab both provide a browser-based IDE.
Earlier this year we decided to test Renovate to manage automated dependency updates in our self-hosted GitLab environment. Being able to run Renovate in our own environment and configure it to our needs made a lot of sense. Since we run our internal tooling on a Nomad cluster, we had to configure a Nomad job for Renovate.