If you're actively considering self hosting, I recommend giving forgejo a try. The experience is much more similar to what GitHub offers, actions API is nearly identical to name one similarity of which there are many. Moving essentially becomes one prompt and a coffee later for a small team.

▲

hosh 6 hours ago | parent [-]

If people are happy with Actions API, that sounds great.

I’m not happy with the Actions API. I think Gitlab’s cicd design is much better, and I’m not fighting it all the time when I use it.

▲

dijksterhuis 5 hours ago | parent [-]

i'll echo this sentiment. historically there's been a lot more flexibility with GL CI yaml syntax, including real yaml anchors https://frenck.dev/github-actions-yaml-anchors-aliases-merge...

sys-admin-ing gitlab can be a bit of a maze of web menus tho.

	▲	vinnymac 2 hours ago \| parent \| next [-]
		I find this recommendation funny, because I completely agree from a sysadmin perspective. I used to use Gitlab at work, and small teams would run into so many footguns with CI that we had to throw up guardrails to prevent mistakes. Far too many links to gitlab issues that were not fixed even after >8+ years of being open ended up biting us. With GHA I haven't had that experience, and same for all of my self hosted Forgejo instances. I used to hate using GHA from about ~2018 to 2021, but they've fixed a lot of things I disliked since then.
	▲	spockz 3 hours ago \| parent \| prev [-]
		What do you need real anchors for? Sharing of pipelines? Maybe I’ve been burned too much by pipeline maintenance (because we didn’t have yaml anchors?) but I rather have builds defined in make /bazel/etc than in yaml. So the only thing the pipeline does is optionally restoring caches, kicking off the build system, uploading PR validation results, and saving cache. Pushing artifact etc is all done from inside the build system. There is no “setup” like installing packages because we make the build image seperately.