4 ms·

I'm pessimistic about GitLab, given the state and trajectory of GitLab CI, which should be a core product for them. It's not in a good place, and it's not recei

I'm pessimistic about GitLab, given the state and trajectory of GitLab CI, which should be a core product for them. It's not in a good place, and it's not receiving the attention it needs, for being a core part of their platform. Being required to use GitLab CI causes me pain and frustration on a daily basis. If the other commenters are correct that the new CEO has a track record of pursuing private equity type acquisitions, then I fear GitLab CI is destined to become the next Travis CI.

cyberpunk 2y ago
Wow having gone from gitlab to gh actions I miss gitlab ci massively. GitHub actions still aren’t k8s native, you actually have to install docker on your “runners” like it’s the year 2010. Pitiful.
- lol768 2y ago
  Yeah - and as a result of that, the builds I do for .NET in GitHub Actions are an order of magnitude quicker to run than the previous pipelines I had in GitLab, where everything was painfully slow because it all ran inside Docker. I get the point about it not being ideal for self-hosted runners, not having ephemeral storage etc. But I disagree that the hosted GitHub Actions runners don't provide a good experience. If your build needs it - e.g. you're building something to deploy to your K8s cluster, use your Dockerfile and build in Docker. If you just want to compile some code, what's the point?
datenhorst 2y ago
Can I ask what specific pain points you have with Gitlab CI? I've been using it extensively the last couple of years and all in all it's been a pretty smooth experience!
- RainyDayTmrw 2y ago
  * Doesn't scale. In many places. In particular, GitLab CI is required to use GitLab's Gitaly for Git replication. Gitaly has architectural limitations on throughput, which are surprisingly easy to hit with even a medium sized team. Certain otherwise reasonable patterns, particularly child pipelines, cause severe load amplification with Gitaly. * Bad error handling. Ruby errors leak through. Although the underlying error is my user error, returning it to me as an underlying Ruby exception is really unhelpful. It basically shows that they didn't validate inputs at all. The input is trusted, so it's probably not a security issue, but it's a huge usability and developer experience issue. * Config format is weird and deficient. Surprisingly difficult to programmatically generate. Can't generate new jobs into the current pipeline. Must generate child pipelines. See above for the load amplification issue therein.

cyberpunk 2y ago

Wow having gone from gitlab to gh actions I miss gitlab ci massively. GitHub actions still aren’t k8s native, you actually have to install docker on your “runners” like it’s the year 2010. Pitiful.

lol768 2y ago
Yeah - and as a result of that, the builds I do for .NET in GitHub Actions are an order of magnitude quicker to run than the previous pipelines I had in GitLab, where everything was painfully slow because it all ran inside Docker. I get the point about it not being ideal for self-hosted runners, not having ephemeral storage etc. But I disagree that the hosted GitHub Actions runners don't provide a good experience. If your build needs it - e.g. you're building something to deploy to your K8s cluster, use your Dockerfile and build in Docker. If you just want to compile some code, what's the point?

datenhorst 2y ago

Can I ask what specific pain points you have with Gitlab CI? I've been using it extensively the last couple of years and all in all it's been a pretty smooth experience!

RainyDayTmrw 2y ago
* Doesn't scale. In many places. In particular, GitLab CI is required to use GitLab's Gitaly for Git replication. Gitaly has architectural limitations on throughput, which are surprisingly easy to hit with even a medium sized team. Certain otherwise reasonable patterns, particularly child pipelines, cause severe load amplification with Gitaly. * Bad error handling. Ruby errors leak through. Although the underlying error is my user error, returning it to me as an underlying Ruby exception is really unhelpful. It basically shows that they didn't validate inputs at all. The input is trusted, so it's probably not a security issue, but it's a huge usability and developer experience issue. * Config format is weird and deficient. Surprisingly difficult to programmatically generate. Can't generate new jobs into the current pipeline. Must generate child pipelines. See above for the load amplification issue therein.