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.
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:
When we made the move to GitLab 1,5 years ago, it was clear to me that we would need some automation to simplify the creation of groups and projects and to sync the LDAP group memberships to the matching GitLab groups. I did a quick search on Packagist for GitLab client libraries and found the m4tthumphrey/php-gitlab-api package.