Comment by vibe_assassin
4 hours ago
I didn't know people disliked GitLab. I use it for work and while some things could definitely be improved, overall I find it to be a pretty intuitive and easy experience. They could definitely improve user management at the admin vs group level (you cant see LDAP sync settings in admin panel, you have to navigate to the group) but overall I don't get frustrated using it. It's CICD syntax is a breeze for the most part too
> It's CICD syntax is a breeze for the most part too
Hard disagree. Gitlab CI, while more powerful than some alternatives, is so so bad, its YAML-based syntax included. As I said in another thread[0]:
> I worked with Gitlab CI on the daily from 2021 till 2024 and I started curating a diary of bugs and surprising behavior I encountered in Gitlab. No matter what I did, every time I touched our CI pipeline code I could be sure to run into yet another Gitlab bug.
[0]: https://news.ycombinator.com/item?id=46296816
I agree that the YAML can get out of hand. We use the `extends` keyword to put together jobs from pieces so that details can live in one place and the job bits and graph description can live in another. The way we've done our pipelines are very difficult to do with GHA as we build a DAG (with splits and forks) that are greatly aided by artifacts being integrated into GitLab-CI instead of separate piecemeal actions.
We also need custom runners anyways because macOS and Windows are important and getting those with graphical session access and/or CUDA hardware in the cloud is either $$$$ or severely limited. Even with our setup, we split the build and test phases so that CUDA hardware slots aren't wasted on running compilers. It also lets us test a single build under different environments easily.
So, yeah, I can see fighting with the feature spectrum, but you need to restrict yourself in most other cases with that kind of stuff too. But at least what we do is possible with GitLab-CI.
Weird, I helped manage a transition of a few hundred repos from GitHub enterprise to Gitlab enterprise, which included helping a few dozen teams migrate their CI to gitlab ci.
I had such a better experience with gitlab CI than any other I have used. There are quirks, but they make sense after you learn them.
Same experience, GitLabs CI/CD language is to me so much better - it has really strong abstractions and you can model a lot of developer experience into it. Especially when it comes to security practices of GitLab CI, but also custom runners, web terminals, ... there is just so much that is shining much more than any other Git forge with built-in CI/CD.
In general you shouldn’t be letting your ci system’s job orchestration be handled in YAML. It’s just too complex of a concept to try and capture in some half baked YAML DSL
Agreed. As the saying goes,
> every sufficiently complex CI system becomes indistinguishable from a build system.
But what alternatives are there that also integrate well with version control systems like GitLab/GitHub/Gitea/…?
For instance, Dagger works quite well but its UI is going to be completely separate from whatever CI system you're using.
I can't imagine a world where I had to work with the Gitlab CI pipeline on the daily. I'm sure it's not perfect, but what are you even doing if you have to touch it DAILY?!
I didn't mean to say I changed the pipelines on the daily, though admittedly I did have to touch them rather frequently since we were migrating stuff away from Jenkins.
I dislike the UI a lot. I find it very confusing.
Github is so much easier to use. I don't understand why gitlab wants to make everything so complicated.
Honestly for me Github is really confusing. In Gitlab if I want to see a list of commits, I click on commits, for branches I click on branches, issues on issues, etc. . On Github there are Issues as a toplevel thing, but for commits I need to click a weird history button on the project homepage. Traversing and querying commits is so complicated that I often just give up and clone the project instead.