I prefer Forgejo, but both it and Gitea support actions like GitHub's. You can have a nice CI/CD pipeline that runs 100% in-house, for free. I adore it for personal projects.
I want to signal boost the following quote from the URL above:
> Forgejo was created in October 2022 after a for profit company took over the Gitea project. It exists under the umbrella of a non-profit organization, Codeberg e.V. and is developed in the interest of the general public. In the year that followed, this difference in governance led to choices that made Forgejo significantly and durably different from Gitea.
If you take it at face value (at your peril), Gitea is about to start enshittification, while Forgejo will not at any point. My personal opinion, is that this is credible.
I bounced away from Gitea because they don't (last time I checked) have OIDC. I started[0] trying to revive-and-drive a previous PR[1] to add it, but the test failures are beyond my motivation to investigate and resolve.
While GitHub and GitLab have dedicated design and front-end teams to improve their UI/UX, Gitea and Forgejo aren't large enough to reach that scale, even after Gitea became a company.
For example, look at the number of issues triaged with "UX" [0] or "UX Paper Cut" [1] on GitLab. It is an order of magnitude larger than you would find in any other FOSS option.
Sorry but the GitLab UI was bad, is bad, the whole software feels clunky and slow to use and everything is nested where in comparison Gitea is simple, intuitive and straightforward, just like the old Github days. I also don't know if it's a good sign that there are a lot of UX issues?
In my experience, the "really good" is that it comes batteries included:
- completely docker based CI/CD which makes reasoning about what it's going to do easier than "read through some minified .js from some rando"
- they do have composable CI/CD akin to the GitHub Actions marketplace, but I haven't used it as much in anger to speak to how valuable it is versus "competitive checkbox feature"
- built-in Terraform State, so no more S3 + Dynamo
- highly configurable JWT claim curation for ease of OIDC based access from the pipelines
- good integration between the platform and multiple Kubernetes clusters
- related to that, a strong "review environment" setup
- they were also hinting at being a Sentry replacement, but regrettably I had to switch back to GitHub before that came out of preview so I don't this second know where it stands
GitLab doesn't have an equivalent of GitHub actions (except an alpha-quality prototype).
GitHub Actions can share runtime environment, which makes them cheap to compose. GitLab components are separately launched Docker containers, which makes them heavyweight and unsuitable for small things (e.g. a CI component can't install a dependency or set configuration for your build, because your build won't be running there).
The components aren't even actual components. They're just YAML templates concatenated with other YAML that appends lines to a bash script. This means you can't write smart integrations that refer to things like "the output path of the Build component", because there's no such entity. It's just some bash with some env var.
Pedantically I think GLCI treats every environment the same, but by review environments I meant "disposable copies of the app such that one could interact with it during merge request review" e.g. https://mr-8675.example.com corresponding to /example/-/merge_request/8675 that would be provisioned when the MR was opened and torn down when the MR was merged or closed
I believe it aligns with this behavior in GitHub: <https://docs.github.com/en/actions/how-tos/deploy/configure-...> with the distinction that it appears from the GH docs that they think of that as "needs administrative approval" whereas GLCI thinks of it as "if the pipeline has permissions to run provisioning, off to the races, because names are free"
GitLab introduced the "deployment tier" I think as a means of communication to other users about the importance of the environment, but control over what credentials were made available to CI/CD was always controlled via <https://docs.gitlab.com/ci/environments/#limit-the-environme...> which partially explains why the only reason to involve a repository administrator would be to install or update a secret needed to deploy successfully
“Really good” under which metric? Because it is slow, even more confusing after the terrible sidebar redesign and, to quote a famous author, its usage does not spark any joy.
Codeberg and gitea, on the other hand, feel great, like early Github. Fast and simple, instead of a product that’s adding feature on top of half-baked feature to capture the sweet corporate $$$.
I have to agree. I recently joined a company using Gitlab, coming from years of GitHub only. I have a soft spot for underdogs but I already found many features with bugs (especially related to hierarchy and inheritance) that makes you feel "meh".
I feel like all new AI tools only integrate with GitHub though, like Claude Code. We're actually thinking of moving from GitLab to GitHub, just for this reason.
Is that a problem with GitLab or a problem that should make you wary of Claude Code though? It's one thing to lock yourself into one LLM provider, but when they start chaining you to other SaSS organizations aren't they just locking you down even more?
It's... ok. But many of the really useful features are paid. E.g. merge trains or mandatory reviews.
I also don't think "it's open source!" is a huge differentiator because it's enormous, difficult to deploy from source and written in Ruby so the chance of being able to actually modify it for some feature you want is near zero.
I think Forgejo is probably a way better option at this point even if it is less mature. It's written in Go so way easier to deploy and edit. And none of the features are paid.
I do like Gitlab but... it's not amazing. I liked Phabricator more (except for its lack of integrated CI).
It isn't. Ruby lacks static typing, and Rails heavily uses generated identifiers, which means navigating a huge codebase like Gitlab is basically impossible unless it's your full time job (or you get lucky). I've tried. I kept finding methods that - based on a grep - were never called from anywhere, and there's no IDE support for something like Find All References.
I'm sure if it was your full time job you'd eventually learn the codebase, but there's no way you can just dip in and add a feature unless you really persevere.
But I did manage to add a few features to the gitlab-runner (used for CI) - because it's written in Go, and Go has static types and pretty great IDE support these days. Night and day.
I've also added a few features to VSCode which is a similarly huge codebase. Again it's written in Typescript which has static types and good IDE support. It would have been effectively impossible if that wasn't the case.
I'll plug another option Gitpatch, however it's pretty early beta and not open-source yet, but most likely will be under AGPL at some point. It has built-in patch stacks (aka stacked PRs) and probably faster than any other Git host out there.
disclosure: I'm the author.
GitLab has a ton of options, And I find myself a bit overwhelmed by the user interface. It really needs a UX lead to simplify and create a better information architecture.
And, if you don't like something there's a very good chance you could be the change you want to see - they have a pretty welcoming contribution culture. Even if you don't want to change something, being able to read the source for it goes a long way toward aligning your understanding of the behavior, and that's not a diss on their usually pretty good documentation
GitLab is great - but super fat. The performance will suffer heavily if you don't give it the resources it wants (all RAM you can find, lol).
If you only need Git plus project tracking Gitea is super mature. It runs happily on small VPS.
I prefer Forgejo, but both it and Gitea support actions like GitHub's. You can have a nice CI/CD pipeline that runs 100% in-house, for free. I adore it for personal projects.
> You can have a nice CI/CD pipeline that runs 100% in-house, for free.
Interested! Some detail on how you achieve this for free would be great.
3 replies →
> Gitea support actions like GitHub's
Citation needed. nektos/act is for sure not "like GitHub's"
4 replies →
Gitea is neat, and the Actions compatibility is promising. Though I’d suggest a fork, Forgejo: https://forgejo.org/compare-to-gitea/
I want to signal boost the following quote from the URL above:
> Forgejo was created in October 2022 after a for profit company took over the Gitea project. It exists under the umbrella of a non-profit organization, Codeberg e.V. and is developed in the interest of the general public. In the year that followed, this difference in governance led to choices that made Forgejo significantly and durably different from Gitea.
If you take it at face value (at your peril), Gitea is about to start enshittification, while Forgejo will not at any point. My personal opinion, is that this is credible.
3 replies →
Thank you for the recommendation.
Will move to that fork in one of my future private infrastructure reconstructions.
I bounced away from Gitea because they don't (last time I checked) have OIDC. I started[0] trying to revive-and-drive a previous PR[1] to add it, but the test failures are beyond my motivation to investigate and resolve.
[0] https://github.com/go-gitea/gitea/pull/33945
[1] https://github.com/go-gitea/gitea/pull/25664
OIDC = OpenID Connect, an open authentication protocol
Gitea's UI is ugly.
While GitHub and GitLab have dedicated design and front-end teams to improve their UI/UX, Gitea and Forgejo aren't large enough to reach that scale, even after Gitea became a company.
For example, look at the number of issues triaged with "UX" [0] or "UX Paper Cut" [1] on GitLab. It is an order of magnitude larger than you would find in any other FOSS option.
[0]: https://gitlab.com/gitlab-org/gitlab/-/issues/?label_name%5B...
[1]: https://gitlab.com/gitlab-org/gitlab/-/issues/?label_name%5B...
Sorry but the GitLab UI was bad, is bad, the whole software feels clunky and slow to use and everything is nested where in comparison Gitea is simple, intuitive and straightforward, just like the old Github days. I also don't know if it's a good sign that there are a lot of UX issues?
In my experience, the "really good" is that it comes batteries included:
- completely docker based CI/CD which makes reasoning about what it's going to do easier than "read through some minified .js from some rando"
- they do have composable CI/CD akin to the GitHub Actions marketplace, but I haven't used it as much in anger to speak to how valuable it is versus "competitive checkbox feature"
- built-in Terraform State, so no more S3 + Dynamo
- highly configurable JWT claim curation for ease of OIDC based access from the pipelines
- good integration between the platform and multiple Kubernetes clusters
- related to that, a strong "review environment" setup
- they were also hinting at being a Sentry replacement, but regrettably I had to switch back to GitHub before that came out of preview so I don't this second know where it stands
GitLab doesn't have an equivalent of GitHub actions (except an alpha-quality prototype).
GitHub Actions can share runtime environment, which makes them cheap to compose. GitLab components are separately launched Docker containers, which makes them heavyweight and unsuitable for small things (e.g. a CI component can't install a dependency or set configuration for your build, because your build won't be running there).
The components aren't even actual components. They're just YAML templates concatenated with other YAML that appends lines to a bash script. This means you can't write smart integrations that refer to things like "the output path of the Build component", because there's no such entity. It's just some bash with some env var.
I can map most of the list but I can't recall what would be the "review environment setup" What did you mean by that?
Pedantically I think GLCI treats every environment the same, but by review environments I meant "disposable copies of the app such that one could interact with it during merge request review" e.g. https://mr-8675.example.com corresponding to /example/-/merge_request/8675 that would be provisioned when the MR was opened and torn down when the MR was merged or closed
<https://docs.gitlab.com/ci/yaml/#environment> plus <https://docs.gitlab.com/ci/yaml/#dynamic-environments> et al
I believe it aligns with this behavior in GitHub: <https://docs.github.com/en/actions/how-tos/deploy/configure-...> with the distinction that it appears from the GH docs that they think of that as "needs administrative approval" whereas GLCI thinks of it as "if the pipeline has permissions to run provisioning, off to the races, because names are free"
GitLab introduced the "deployment tier" I think as a means of communication to other users about the importance of the environment, but control over what credentials were made available to CI/CD was always controlled via <https://docs.gitlab.com/ci/environments/#limit-the-environme...> which partially explains why the only reason to involve a repository administrator would be to install or update a secret needed to deploy successfully
---
it the spirit of "they really, really drink their own champagne," one can see the environments for GitLab itself https://gitlab.com/gitlab-org/gitlab/-/environments
“Really good” under which metric? Because it is slow, even more confusing after the terrible sidebar redesign and, to quote a famous author, its usage does not spark any joy.
Codeberg and gitea, on the other hand, feel great, like early Github. Fast and simple, instead of a product that’s adding feature on top of half-baked feature to capture the sweet corporate $$$.
Really good if you go by a feature checklist, probably. A bloated clutter of more or less working features, checking enterprise boxes.
I have to agree. I recently joined a company using Gitlab, coming from years of GitHub only. I have a soft spot for underdogs but I already found many features with bugs (especially related to hierarchy and inheritance) that makes you feel "meh".
I feel like all new AI tools only integrate with GitHub though, like Claude Code. We're actually thinking of moving from GitLab to GitHub, just for this reason.
Is that a problem with GitLab or a problem that should make you wary of Claude Code though? It's one thing to lock yourself into one LLM provider, but when they start chaining you to other SaSS organizations aren't they just locking you down even more?
In some industries, all the tools you actually need (say, MISRA checking) all work with GitLab out of the box.
same reason why we didn't leave github yet
most SaaS tools only have github integration which is sucks
Claude works great with forgejo/gitea. It's all just git, after all.
It's... ok. But many of the really useful features are paid. E.g. merge trains or mandatory reviews.
I also don't think "it's open source!" is a huge differentiator because it's enormous, difficult to deploy from source and written in Ruby so the chance of being able to actually modify it for some feature you want is near zero.
I think Forgejo is probably a way better option at this point even if it is less mature. It's written in Go so way easier to deploy and edit. And none of the features are paid.
I do like Gitlab but... it's not amazing. I liked Phabricator more (except for its lack of integrated CI).
> written in Ruby so the chance of being able to actually modify it for some feature you want is near zero
That's a silly thing to say.
It isn't. Ruby lacks static typing, and Rails heavily uses generated identifiers, which means navigating a huge codebase like Gitlab is basically impossible unless it's your full time job (or you get lucky). I've tried. I kept finding methods that - based on a grep - were never called from anywhere, and there's no IDE support for something like Find All References.
I'm sure if it was your full time job you'd eventually learn the codebase, but there's no way you can just dip in and add a feature unless you really persevere.
But I did manage to add a few features to the gitlab-runner (used for CI) - because it's written in Go, and Go has static types and pretty great IDE support these days. Night and day.
I've also added a few features to VSCode which is a similarly huge codebase. Again it's written in Typescript which has static types and good IDE support. It would have been effectively impossible if that wasn't the case.
5 replies →
Every place I write code I use whatever GitHub like thing the admin installed. They all work well enough.
At home I prefer fossil. It isn’t without rough edges but for the small developer headcount stuff I do it is quite lovely.
I'll plug another option Gitpatch, however it's pretty early beta and not open-source yet, but most likely will be under AGPL at some point. It has built-in patch stacks (aka stacked PRs) and probably faster than any other Git host out there. disclosure: I'm the author.
GitLab has a ton of options, And I find myself a bit overwhelmed by the user interface. It really needs a UX lead to simplify and create a better information architecture.
For a couple grand a year, not having to worry about upgrades, backups, hosting cost, etc. is 100% worth it.
It is rumored that Gitlab is about to be aquired. It may not still be open-source after that.
I went there last year due to Microsoft's destruction of github.
And, if you don't like something there's a very good chance you could be the change you want to see - they have a pretty welcoming contribution culture. Even if you don't want to change something, being able to read the source for it goes a long way toward aligning your understanding of the behavior, and that's not a diss on their usually pretty good documentation
GitLab is wonderful but none of the AI tooling supports it and it's expensive.
none of the AI tooling supports it
i consider that a feature
> No need to put your codebase in the "cloud."
Yes and no. If all you want is a remote git server then no, there's not. But there's plenty of legitimate reasons to use a SaaS tool like GitHub.
Gitlab is like the SAP of git, something for bloated big corporations. I've never seen a single FOSS repo there.
Yeah, who's ever heard of this weird company named nvidia <https://gitlab.com/nvidia>, or inkscape <https://gitlab.com/inkscape/inkscape>, or F-Droid <https://gitlab.com/fdroid/fdroidclient>
In what world does nvidia fall under FOSS and not big corporation? That seems like an odd example to lead with.
1 reply →
The entire KDE ecosystem is on gitlab
https://community.kde.org/Infrastructure/GitLab
I don't care much for gitlab either, but for example inkscape lives there
https://gitlab.com/inkscape/inkscape
Didn't nobody ever tell you to "never say never" ?
Knot DNS[1] good enough for you ? GPL licensed.
[1] https://gitlab.nic.cz/knot/knot-dns
https://gitlab.freedesktop.org/ - Freedesktop which is the org for many projects such as Wayland uses gitlab
https://gitlab.gnome.org/ - GNOME uses Gitlab
https://gitlab.com/kicad/ - KiCad uses Gitlab
and https://salsa.debian.org/public - Debian uses Gitlab.
It seems somewhat popular for developers who want to avoid github. Gnome and KiCAD also use it.