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.

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

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