Personally, I quite liked GitLab CI when I used it circa 2021-23. Just now I did a quick search and found this article^1 suggesting (even before this GH pricing change) Gitlab CI may be a better choice than Github Actions.

1. https://medium.com/@the_atomic_architect/github-vs-gitlab-20...

▲

nhumrich 6 days ago | parent | next [-]

I LOVE gitlab, but their new pricing is absurd. It feels like they are trying to shovelware their AI stuff. Their cheapest plan is more than 7x the cost of github, AND more expensive than github enterprise! And thats on the _cheapest_ non free gitlab plan. If you self host gitlab entirely, you can't even get branch/force-push protection. If they could bring their pricing to even just 2x github by having a NON-AI plan, I would purchase again in a heartbeat.

	▲	salzig 6 days ago \| parent \| next [-]
		You mean "Protected branches"? Last time I checked that was part of the free tier, and the documentation[0] states the same. [0]: https://docs.gitlab.com/user/project/repository/branches/pro...
	▲	notnullorvoid 6 days ago \| parent \| prev [-]
		I had to go check to see what their pricing was, and I couldn't believe it. The base tier was $4/month, now that tier is gone and the premium tier is 2x what it used to be only 5 years ago.

▲

Arubis 6 days ago | parent | prev | next [-]

GitLab CI is _excellent_. Github Actions has come a long way, but a few years back it was absolutely painful working with GA when I had GitLab CI for reference.

▲

esseph 6 days ago | parent | prev | next [-]

GitLab CI is quite good. Have been using it for several years.

▲

pornel 6 days ago | parent [-]

I can't tolerate it.

The split between tag and branch pipelines seems like intentional obfuscation with no upsides (you can't build non-latest commit from a branch, and when you use a tag to select the commit, GitLab intentionally hides all branch-related info, and skips jobs that depend on branch names).

"CI components" are not really components, but copy-paste of YAML into global state. Merging of jobs merges objects but not arrays, making composition unreliable or impossible.

The `steps` are still unstable/experimental. Composing multiple steps either is a mess of appending lines of bash, or you have go all the way in the other direction and build layered Docker images.

I could go on all day. Programming in YAML is annoying, and GitLab is full of issues that make it even clunkier than it needs to be.

▲

opello 6 days ago | parent | next [-]

My ready example of a GitLab pain point is parallel matrix job names include the matrix variables and quite easily, in complex configurations, exceed the static 255 character limit of job names, preventing job creation/execution.

There's been years of discussion about ways to fix it with nothing moving forward.

https://gitlab.com/gitlab-org/gitlab/-/issues/263401

And the most recent tracking issue:

https://gitlab.com/gitlab-org/gitlab/-/issues/285853

▲

sangeeth96 6 days ago | parent | prev | next [-]

I have fond memories of using GitLab CI in 2018–2019 and I'm still pissed GitHub didn't just life and shift that kind of a model. Not sure about the particular issues you're running into but I remember GitLab supporting a lot of the YAML features missing in GitHub like anchors in order to build/compose stuff.

Oh and turns out GitHub also has that now: https://github.blog/changelog/2025-09-18-actions-yaml-anchor...

UPDATE: okay they botched it https://frenck.dev/github-actions-yaml-anchors-aliases-merge...

▲

codethief 6 days ago | parent | prev [-]

Agreed. 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.

	▲	BlackjackCF 6 days ago \| parent [-]
		This is also my experience with GitLab CI. It’s great if you have relatively simple CI. If you have anything slightly more complicated (like multiple child pipelines for a monorepo) you’re going to have a rough time. Every time I thought I understood GitLab CI, it would fail/behave in non-obvious ways.

▲

inchidi 6 days ago | parent | prev [-]

used to self-host gitlab CI runners around the same year also for our long running CI's due to db migrations + prepared data loading for tests. we rent 7*4$ VPS, install gitlab CI runners on them, saving us from hundreds $$$ per month and 45mins/merge (with test running on main branch only) to 7*4$/month and 7-9mins/commit (yes, we run full test on each commit and let gitlab auto-cancel older one). with bonus: FE team get live version of their changes on each MR.

* its 7 VPS because we separated the tests by modules and we have 7 major modules. * edit: formatting