The parent's post aligns with my own experience. I've been using GitLab for 2 years after switching companies and I can't think of anything that is an improvement over GitHub.

I never had any issues GitHub Actions for CI stuff at my previous two companies, both which used it heavily. GitLab CI also works fine, though I struggle to see how anyone could strongly prefer one or the other as my own experience is that they basically work the same. Both basically boil down to some yaml you can use to configure running stuff in docker containers.

the rabbit hole goes deep, but both GitLab and GitHub reached parity around that time. (initially GitLab CI simply did a lot more, then GHA kind of took over with the ability to run multiple parallel workflows, and by arguably feeling a bit newer and having better "official" steps ... the GitLab auto-magic CI was ... always completely meh, IMHO.)

but GitLab kept adding the good stuff that Actions introduced, and it can do a lot of things, and with the Omnibus package it's very easy to self-host. (and upgrades are well supported, etc.) ... and of course GitHub self-hosting is only for enterprise editions.

sure, you can setup one GHA Runner on one VM (and each one one a new one), but that's it. nothing else is supported officially.

The point is that it was GitHub that caught up for some simpler use-cases fairly recently, not the other way around. When I started using GitLab 6 years ago it made GitHub look like a toy where you had to reach for external services like Travis to do anything useful.

Fair enough, but the fact that GitLab was better 6 years ago doesn't do much to help the company right now.

I wasn't using GitLab 6 years ago so I can't comment on that, but I can comment that at least since 2022, I haven't found anything in GitLab that would recommend it over GitHub.

> Fair enough, but the fact that GitLab was better 6 years ago doesn't do much to help the company right now.

I don't think you got the point.

The whole point is that a couple of years ago GitLab was unquestionably the market leader and hands down the best service.

And since then it didn't got worse.

Best case scenario, alternatives like GitHub managed to put together similar offerings. That does not mean GitHub suddenly was the best. Far from it. Again, others in this thread used the term "mediocre" to describe GitHub, and this happens years after GitHub started to try to catch up.

To me, GitLab's CICD is by far the absolute best CICD system around. It has been like this for maybe a decade now. The container-centric approach to build jobs, a domain model for pipelines that is extremely simple and yet misses no usecase at all, UX that's unparalleled to the point that, unlike other CICD systems, doesn't even require a tutorial to get the basics to work... Things are so far apart that it boggles the mind how anyone who has any experience in CICD would even mention GitHub on the same sentence.

GitLab was the absolute best 6 years ago and, in spite of Microsoft's takeover of GitHub and rushing to bridge the gap, it still is. That's the whole point.

How is CI not a solved problem with GitHub Actions? I used and loved GitLab CI years ago and remember it feeling better to use than GHA (though maybe I’m remembering through rose tainted glasses), but GHA are just working nowadays, and the ecosystem of pre-made Actions is in good shape.

nope, GHA is still clunky.

self-hosting GHA Runners (plural!) is ... hard (not impossible, and quite doable with enough investment, especially if one takes the dive into the murky waters of k8s), but it's not officially supported. (what's supported is here's a tarball we support these distros ... have fun.)

programming in YAML is still bad, composability is still an afterthought, etc.

For hosted runners that might be true. The best experience I’ve had with GHA self hosted runners was simply using a beefy VPS. At my current job, the self hosted runners were hosted on K8s using Arc and it was a… very unpleasant experience. We switched back to GH runners (turns out the free minutes + a few bucks a month is enough for our use case), but if we need to go back to self hosted I’ll advocate for a VPS.

> programming in YAML is still bad, composability is still an afterthought, etc.

I disagree on that. GitHub actions are as composable as it gets thanks to the ecosystem of actions. GHA is better than GitLab CI in this regard, and probably the best system I’ve used so far. It IS a bit clunky but overall I’ve been pretty satisfied with it.

I also disagree regarding YAML because you don’t program a CI, it’s mostly declarative work. The only conditions needed are a bit clunky to setup, I give you that, but it encourages to either keep the CI simple (no CI needs overly complex conditions), or move the logic to CI scripts in any scripting language.

Thought I'd plug my product because of the mention of actions-runner-controller on k8s. I wouldn't wish that on my worst enemy :)

It is a terrible experience riddled with many gotchas. I'm making WarpBuild to provide runners (cloud and BYOC on user's aws account) to provide more powerful, faster, and overall much better experience. Try us out - you're guaranteed to save both money and time.

Interesting, bookmarking for later :)

it has to be reusable to be composable, ie. it needs some genericness, customization, etc. that usually requires logic, passing args, env vars, etc.

yes, writing programs (ie. an action) is the correct level of abstraction, but in general it just doesn't make much sense to have separate steps. (because for many cases unit testing and building artifacts can/should be done at the same time ... for example python/rust ... inside a container, download deps, build, then run tests, copy result to new layer, push)

> self-hosting GHA Runners (plural!) is ... hard (not impossible, and quite doable with enough investment, especially if one takes the dive into the murky waters of k8s)

I’m the maintainer of RunsOn (https://github.com/runs-on/runs-on), which solves this problem with far less investment