|
> Their CI/CD pipelines also seem a bit more refined than GitHub actions - maybe it is just a maturity thing though? That could also just be my inexperience with GitHub Actions. My experience with CI/CD is that github action's is stellar, while gitlab-ci is a huge mess of features that don't compose well. For instance, in gitlab-ci, you can specify that the job should only run when a specific file changes with `only:rules`, very useful for monorepo setups. Separately, you can specify explicit dependencies in your steps to construct a sort of DAG of your steps with `needs`. Those two features independently work great, but when used together, things become very weird, down to causing YAML parsing errors... Another similar experience: Child pipelines are a mess. Child pipelines can't depend on the parent steps, can't download artifacts from the parent steps. Similarly, the parent can't access the child pipeline' artifact. CI has some fun interaction with bot accounts. By fun, I've had MRs started by bot accounts running in weird CI contexts where some environment variables were not set for whatever reason. Overall, gitlab-ci feels... poor. Github-actions, on the other hand, has been a joy to use, and is a lot less surprising. Most features tend to be thoughtfully designed and work well together. I can't give many examples here as it's hard to point out things that just work, but I've done extensive work with both gitlab-ci and a github actions and I certainly prefer working with github actions any time of day. |