Gitlab tries to do a lot and never did anything that well. It's just perpetually catching up to github.
Github may have beaten Gitlab to the punch with Pages (whoopee) but CI is a far more important feature, and Gitlab CI existed for years before GA, and continued to be a far superior solution for a long time (and maybe it still is?).
Also, because Gitlab targeted enterprises they had a bunch of features that Github did not. Self hosting, Identity and role based access, weighted issues, project milestones and burndown charts, private issues, support for "innersourcing" of internal repositories. The list goes. Unlike Pages, which is useful but can be replaced by any other wiki, things like role based access to projects are really important. When I switched jobs a few years ago and had to use Github, it felt more like a hobbyist's web-based toy version, lacking a lot of "big-boy" features.
The one truly essential feature that separated them "for the 99%" was CI. Once Github introduced that, it shrunk Gitlab's lead.
But Gitlab are by no means playing catchup to to Github.
Totally agree on CI being superior. The config syntax is a bit of a pain and is aching for some higher level abstraction. But it’s very powerful, e.g. easily supporting cross project dependencies and build status across project in one neat interface.
I also agree that GitLab was optimized for enterprise and that’s where the major feature disparity is. If you are using it only for small hobby projects you will feel that it’s nothing special. I’ve used a self hosted version at a fortune 100 and it was a huge boon to productivity there over GH EE.
CI/CD components (GA since 17.0) improve the situation a notch: https://docs.gitlab.com/ee/ci/components/
I find this remark baffling by how much it contrasts with reality. Others in this thread already commented on GitHub using terms like "mediocre". I wouldn't go that far but I am indeed aware that GitLab feels it works and is expected to work reliably, specially CICD which, unlike GitHub, they succeeded in turning it into a solved problem.
It's even more baffling reading bold claims like "Gitlab tries to do a lot and never did anything that well" when only a couple of years ago GitHub Actions were renowned for not even being prod-ready,whereas GitHub CICD just works and works well without requiring investing any thought into it at all.
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.
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.
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.
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.
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.
> 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.
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.
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)
I’m the maintainer of RunsOn (https://github.com/runs-on/runs-on), which solves this problem with far less investment
Last time I used it, which was a few years ago now, it felt like Github had caught up and a lot of the Gitlab features were flaky or didn't seem to serve any purpose other than checking a sales tick list. Stuff like integrations that don't seem to really serve any purpose other than to say they are integrated.
I don't think integrations are the example you think it is. The ones I tried work well and make it trivial to setup features that would otherwise feel like papercuts. I'm talking about things like being able to handle gitlab events without having to manage anything or provide your own event-handling infrastructure. If you have web hooks you need invoke or react to, as anyone who runs full CICD and cares about blocked pipelines does, with GitLab you don't need to worry about exposing custom endpoints and write controllers. For many, that is the difference between using notifications or not.
That's not how I remember it. I agree that GitHub is ultimately the more polished product, which is why I eventually went back with my personal projects to it... But most of these platform features like CI Integrations, project repositories etc started at gitlab, and GitHub effectively copied them later
I do wish Gitlab would spend some time better organizing their settings menus, but aside from that it seems to be more complete.