Comment by wongarsu
20 hours ago
I'd also say that gitlab runners are the biggest failure point in gitlab and take some work to micro-manage. If I was setting up from scratch I would consider gitlab for source control, but some hosted service for CI
20 hours ago
I'd also say that gitlab runners are the biggest failure point in gitlab and take some work to micro-manage. If I was setting up from scratch I would consider gitlab for source control, but some hosted service for CI
Really? I've been very happy with how easy GitLab Runners are to manage. We were running 20,000 jobs a week on 6 bare metal boxes and we had tons of spare capacity. Simple Ansible script to deploy the runner and register it. Tags for t-shirt sizes to set the amount of CPU/memory allocated to each job container.
Maybe running on Kubernetes or some autoscaling solution is more painful.
When it works, it's great. When it doesn't, good luck figuring out why.
When you fork a project, it's really not clear in the UI why it's stalling (because it uses your configured runner, i.e. none, not the project's).
When a runner fails, it's not really clear why. gitlab-runner logs are mostly useless in terms of connectivity to the gitlab instance, displaying what projects/repos it's effectively associated with. And i don't think it even has a simple test command to test the docker setup, you just have to trigger jobs until it fails in the middle of hundreds of lines of logs.
Maybe give https://rocketrunner.io a try? We made super easy and fully managed GitLab CI/CD runners for GitLab.com or self-hosted GitLab servers :-)
(Sorry for posting this twice, but we'd really love to get more user feedback)