gitlab-ci.yml
Have you ever been debugging a pipeline job and keep having to go add bash commands, like set -x or a thousand echo statements to figure out what is going on?
Well there's an easier way! You can simply add a CI/CD variable to your project (or group) and automatically get debug output without having to make a branch/MR or changes to your scripts!
As more and more DevOps teams adopt GitLab for internal development, and furthermore use GitLab CI/CD pipelines, finding ways to manage costs while still delivering highly available, scalable pipelines is crucial.
In this post I will provide an overview of GitLab runners and their role in CI/CD pipelines, as well as how you can configure your own self-managed runners using the Kubernetes executor running in your own EKS cluster.
At a high level, a GitLab runner is an agent that runs CI jobs in your pipeline. This can be in the form of agents running on Linux, Windows, or Mac hosts, as well as Docker or Kubernetes.