> 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

▲

javier2 an hour ago | parent | next [-]

Well, I have used a lot of Github Action too, and Gitlab is by far easier to do fairly complicated stuff with, but Github Actions has much better re-usability if you need to re-use or share parts of the job with all projects you build.

	▲	trueismywork an hour ago \| parent [-]
		GitLab is now getting steps and has components.

▲

mathstuf 4 hours ago | parent | prev | next [-]

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.

▲

cortesoft 4 hours ago | parent | prev | next [-]

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.

	▲	miduil 3 hours ago \| parent [-]
		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.

▲

SOLAR_FIELDS 6 hours ago | parent | prev | next [-]

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

▲

codethief 6 hours ago | parent [-]

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.

	▲	SOLAR_FIELDS 2 hours ago \| parent [-]
		the pattern I recommend is to use CI system only at the event trigger layer e.g. setting up invocation as a response to webhooks. Then you drop down into whatever orchestration layer you implement yourself to do the actual work. So in my configurations, the ci yml is very minimal, it essentially says "set up env vars, inject secrets, install minimal deps and invoke `ci` command of whatever adult system you so choose" (Dagger would be one example). What UI are you looking for outside of log streaming? If you want to see a DAG of your workflows and their progress you can use other systems as you say (Dagger has this), or your orchestration layer can implement that. If you want to use the orchestration component of your ci tooling, you always can do so, and get your DAG viewer, but you have to accept all of the constraints that come with that choice

▲

sippeangelo 6 hours ago | parent | prev [-]

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?!

	▲	codethief 5 hours ago \| parent [-]
		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.