I’ve liked using GitLab but it’s definitely felt like their IPO lead to more chasing flash and less attention to quality. They yanked the support rep which customers used to get–everything goes through sales now–and started putting most features behind the hefty Ultimate price tier, and there are so many cute features which need more polish but since they’re not “AI” it seems like they’re ignored even though they have open issues with years of customers saying they have the same problem.
This has lead to a game: each time the sale pitch claiming big wins for their AI tools arrives, ask “when will we start seeing GitLab development back to pre-IPO speed?”
Nah, they were always chasing flash. I enjoyed using their products circa 2015-2020, but man they really leaned into the Pareto Principle. Every feature had rough edges, and they didn’t invest much in polish.
It’s a tough trade-off for a small team competing with a behemoth, and I guess their success indicates that they played their hand correctly. If you are going for the enterprise segment then checking off the feature requirements can be more important than making each feature perfect.
I don’t think it was perfect back then either but it felt like it got worse. I think this may prove a strategic error: checking all of those enterprise boxes gets you in the door but they don’t have Microsoft’s clout in that market and depend on technical staff pushing for them over GitHub.
>Speed. The GitLab web interface has always felt sluggish to me.
10 years later the same problem remains. While Gitea / Forgejo have very little performance problems. And will only get better once Go 1.26 is out. Which is a much bigger release than a single digit version number upgrade.
I used GitLab only as a remote repo for private projects, no CI at all. The laggy interface and that damn browser check every so often made me close my account.
It must be a fundamental architectural problem with Gitlab. When I had to use it for work the speed killed me. Especially searching for issues. I will never consider gitlab for anything until they find a way to boost performance.
Github can get pretty sluggish as well; if you have a pull request with lots of comments page loads begin to take a dozen seconds or more. AI code review bots make it painful for humans to use it.
I dont think that is true, consider Fuzzy, Hey, Basecamp, Shopify all seems to be doing fine. Shopify actually got impressively fast in the recent two years I have no idea why. Github used to be fast as well.
So while Go by default will always be faster then Ruby Rails, there are plenty of examples of decently fast Ruby Rails Apps. Having 10 years saying they will improve performance and not getting any of it suggest problems with Gitlab itself more than RoR.
Yeah, from my experience administering a pretty small self-hosted instance, I think it's got to be this. Every single admin action you try to take on the backend is SLOWWWWW. Restarting the services takes a few minutes. Just to bring up an admin console on the server in a CLI takes well over a minute, which indicates a tremendous amount of overhead purely on the ruby side.
There's just something fundamentally slow about how it's all put together. I wouldn't blame the language or tech stack, exactly - but perhaps Ruby on Rails is not a great fit, anymore, for a fully featured forge of this scale?
Foreman is a great piece of software for host configuration management.... except for the fact that it's written in Ruby. It takes like 3sec to load the parameters page, and for that reason, it should never be used.
Very weird, my experience is the opposite. When changing jobs in 2018 I moved from Bitbucket and Confluence (own data center, but to my understanding powerful and well-maintained) to Gitlab cloud. Atlassian was laggy, overengineered and not pleasant to use. Gitlab was slim and fast. They have added a lot of stuff since then and maybe smreponsiveness has suffered a bit, but I can't really complain. Gitlab works well most of the time. Recently I have had to use Jira cloud. Much worse than Gitlab. Could be that our templates are overloaded and some extensions are particularly bad (looking at you XRay). But pretty sluggish and annoying user experience. With Gitlab over-excited managers cannot ruin performance by having more and more details added to the templates.
jira, bitbuck, etc historically and currently are all slow(still faster than they used to be, considerably so). So in comparison to a set of tools I have always seen talked about as slow, gitlab is faster.
Just like a truck will always be more sluggish than a small car. They are very different beasts where one is aimed at enterprises and the other one for small projects without all the corporate needs.
"It's enterprise" it's such a lame excuse, IMO. There shouldn't be a speed tax, especially if you aren't using the "enterprise" features. We need to stop making excuses for bad software. It's 2026 we have insanely powerful computers, why should I have to wait to get the result of searching a few text-only issues or display a diff?
I've been using GitLab since the early days, but a week ago I switched to Forgejo. Power usage on the server dropped by 10%, despite both being idle most of the time.
As the author says, GitLab feels sluggish, and is bloated with 1001 thing I'd never use that just makes the UI a pain. Despite all the features I don't need, some that I would benefit from are disabled in the free version.
Forgejo is simpler. It allows me to hide features per project that I don't need. Bit there are some tradeoffs. Updates on GitLab was great. I've been letting it self update for years with no issues. This does not work on Forgejo. Forgejo is also a lot less polished, and some features just doesn't seem to work like they should.
Tangent, but fantastic website. Honestly it was a pleasure just to read it and click around on it. I'm not sure if the design and idea was your own or part of some Jekyll theme, but the execution is just fantastic. Couldn't find the source in your GitHub repos, but maybe I just didn't look hard enough.
I switched from GitLab to Forgejo for my private projects after not wanting to deal with how slow GitLab's interface is anymore.
I still have proper CI, issue tracking, and all other features I care about, but the interface loads instantly and my screen isn't filled with many features I'll never use for my private projects.
I came here to say this. I switched to forgejo after self hosting gitlab for years, and haven't missed anything.
The article mentions the container registry as a prime feature of gitab. Forgejo has this, btw.
In addition, speed (of everything) is so good with forgejo. The resource requirements (napkin math, but...) are 10% of gitlab.
I see no reason to ever use GitLab again.
There are two minor annoyances for me, but not deal breakers.
.
First, I actually prefer the GitLab CI syntax. "GitHub Actions" is a mess. I suppose it makes sense to use the dominant gorilla (github actions), but converting to this CI was more trouble than it should have been.
Also, the forgejo API: it is much less developed. I did like exploring with GraphQL which is totally missing in forgejo. But, you have access to the database directly (and can use sqlite or postgres, your choice) so you can really do whatever you want with a custom script. Forgejo API and their infrastructure around it is just a bit more clunky, but nothing that was a major problem.
One of the reasons I like how lightweight GitTea/Forgejo is allows me to develop with argocd locally. Spin up a kube cluster with tilt, bootstrap forgejo, bootstrap Argo and point it at forgejo, now I can test Appset devs with sync waves locally
Is there any point to switch to Forgejo for my open source projects? Wouldnt I just be leeching resources from the guys at Codeberg/ whereever instead of Microsoft?
Codeberg _wants_ to host open source projects; it isn't leeching any more than adding articles to Wikipedia.
If you feel guilty, you can self-host Forgejo, contribute to Forgejo, or become a Codeberg member and pay them a yearly fee of your choosing (https://join.codeberg.org/).
Just tried it out for a bit, and it looks great and is super snappy. It seems the CI portion is delivered by a project Woodpecker? How does this work and is compared to gitlab CI?
Forgejo has an integrated CI/CD solution, Forgejo Actions [1], that is very similar to GitHub Actions (and thus not so similar to GitLab CI). This is what you'll probably use if you self-host.
Codeberg (a public Forgejo-based forge) also offers Woodpecker CI. Their hosted Forgejo Actions is still in beta AFAIK, but you can also use your self-hosted runners.
Forgejo's code review tool slavishly follows GitHub (like a lot of other things it does) and so has the same inferior developer workflow that comes with that.
GitLab is no Gerrit, but it does at least support stacked MRs, and at least seeing comments between forced pushes / rebases, if not tracking them.
I use Codeberg, and therefore Forgejo for my open source project, but frankly the GH style workflow is not appropriate for serious software development. It forces one to either squash all commits or use <gag> merge commits. Many people have developed stockholm syndrome around this and can't imagine any other way. But it sucks.
The GH model encourages big-bang giant PR all at once development, and it's corrosive on productivity and review culture inside teams. And it leads to dirty commits in the git history ("fix for review comments." "merge." "fix for review comments." etc)
I worked with GitLab for a year and a half on a job, and I prefer its review tool for functionality, though not necessarily UX.
I didn't know people disliked GitLab. I use it for work and while some things could definitely be improved, overall I find it to be a pretty intuitive and easy experience. They could definitely improve user management at the admin vs group level (you cant see LDAP sync settings in admin panel, you have to navigate to the group) but overall I don't get frustrated using it. It's CICD syntax is a breeze for the most part too
> It's CICD syntax is a breeze for the most part too
Hard disagree. Gitlab CI, while more powerful than some alternatives, is so so bad, its YAML-based syntax included. As I said in another thread[0]:
> 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.
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.
Same experience, GitLabs CI/CD language is to me so much better - it has really strong abstractions and you can model a lot of developer experience into it. Especially when it comes to security practices of GitLab CI, but also custom runners, web terminals, ... there is just so much that is shining much more than any other Git forge with built-in CI/CD.
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.
Well, I have used a lot of Github Action too, and Gitlab is by far easier to do fairly complicated stuff with, but Github Actions has much better re-usability if you need to re-use or share parts of the job with all projects you build.
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
the pattern I recommend is to use CI system only at the event trigger layer e.g. setting up invocation as a response to webhooks. Then you drop down into whatever orchestration layer you implement yourself to do the actual work. So in my configurations, the ci yml is very minimal, it essentially says "set up env vars, inject secrets, install minimal deps and invoke `ci` command of whatever adult system you so choose" (Dagger would be one example).
What UI are you looking for outside of log streaming? If you want to see a DAG of your workflows and their progress you can use other systems as you say (Dagger has this), or your orchestration layer can implement that.
If you want to use the orchestration component of your ci tooling, you always can do so, and get your DAG viewer, but you have to accept all of the constraints that come with that choice
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?!
I didn't mean to say I changed the pipelines on the daily, though admittedly I did have to touch them rather frequently since we were migrating stuff away from Jenkins.
Honestly for me Github is really confusing. In Gitlab if I want to see a list of commits, I click on commits, for branches I click on branches, issues on issues, etc. . On Github there are Issues as a toplevel thing, but for commits I need to click a weird history button on the project homepage. Traversing and querying commits is so complicated that I often just give up and clone the project instead.
> Feature overload. GitLab tries to be everything.
This is the primary reason I dislike GitLab. It is so complicated to use.
Github issue trackers are so simple to use.
Perhaps GitLab offers more features for project owners, but as a user, I much prefer github. Of course I'd prefer it even more if Microsoft wouldn't control github ...
Same. We used to host a GitLab instance in our enterprise. As a sysadmin that used that only occasionally, let me tell you, it took me a hundred times the time to figure out how to do something than actually doing it.
Even just finding the source code or issue tracker was like hidden behind layers of layers in the navigation.
No we're hosting GitHub. Shits never been easier. GitHub also has its ugly sides, but the ugly sides still are better than anything in GitLab.
> The 10GB limit per project sounds small on paper but I’ve never come close to hitting it
The docker images don't have limits, there is a limit per layer. IIRC I've distributed a 100GB image through their free tier (just had to make sure to keep the layer size small enough).
Has someone made a p2d yet where they split a 4K movie into a bunch of docker layers to push and pull through an OCI registry? I have a 70GB REMUX copy of Interstellar that I'd love to docker push to gitlab.
While it‘s pretty great to have such a unified interface, there are many papercuts.
To me it has become a bit of a meme that you always end up in this old-issue flow: I want to do X -> Try it -> Run into an issue -> Search for solution -> Find an official bugreport that is 3-8y old. Also many features seem to be stuck in either the 80/20 hell or it the „we needed a bulletpoint on a feature list and built a barely working MVP“-situation. The slow interface, as mentioned in other comments, is so incredibly painful on MR-views that it drives me crazy some days.
> To me it has become a bit of a meme that you always end up in this old-issue flow: I want to do X -> Try it -> Run into an issue -> Search for solution -> Find an official bugreport that is 3-8y old.
That's been my experience as well and, in fact, it was totally a meme at my former client! See also my comment in another recent thread: https://news.ycombinator.com/item?id=46296816
We switched to gitlab at work about five years ago and this perfectly summarizes my experience. Add to that Gitlab projects also have a included Maven, NPM and python compatible package registry, so you can just push your package back in the CI pipeline is one of my favourite features as a smaller team. My least favorite feature is actually the sheer number of features. There is actually too many features. And the constant waiting. Basically every screen is just twice as slow as I would like to wait.
After using Stash for ages at work we switched to gitlab which was refreshing. It was fast, self hosted, and full of features, especially useful around quality gates and build on PRs. Then it was decided we should go for best of suite instead of breed and we went to azure devops.
It is slow as molasses, issues are more project management oriented instead of coding, quality gates are virtually non existent and builds are now slow. Builds are slow because instead of our beefy build servers they run on VMs, that are undersized and have IOPS restrictions, because downloading the cache for maven/docker/npm is relatively fast but actually expanding it on disk is slow, because just the simple orchestration to spawn a job is also slow.
I would love to go back to gitlab and I would even dedicate some time to performance tune it and contribute back. I think gitlab does everything right. (Technically, not sure about pricing and tiering.)
If you log into your GitLab account from a Hong Kong IP address, they'll delete your account after 60 days and tell you to use JiHu, a Chinese company, instead.
It was once a cool alternative to gitlab. Self hostable, open source, etc... Now it's bloated hell. Everything from source control, to project management. I don't have good experiences with it in recent years
For a long time I self hosted Gitlab, and was always quite happy with it, but I recently moved my VPS and decided to give Forgejo a try, and I have to say it's refreshing. It's really fast and takes a fraction of the resources Gitlab does. I'm sure Gitlab have more features, but frankly, I wasn't using them. I still like Gitlab, we use it at work and it does a good job, but for my own needs I don't see myself switching back any time soon.
It's frustrating that the so-called enterprise solutions are monsters. In a former workplace we were using Gogs for a long time. It's so nice to work with software that doesn't require a ton of resources for a relatively simple task.
We are running GitLab Ultimate in three different environments. Like 2000 users each and each user pipeline runs crazy like hundreds amounts of jobs. GitLab is keeping up. But we are sized for the 40 RPS architecture
Just in case anyone else (like me) didn't get the reference:
> This page describes the GitLab reference architecture designed to target a peak load of 40 requests per second (RPS), the typical peak load of up to 2,000 users, both manual and automated, based on real data.
We used to run Gitlab Premium for around 300 users running hundreds of jobs over some monorepos. Gitlab suggested a small architecture using Omnibus, and while it helped a bit, it didn't perform as well under load as we expected it to.
Eventually, there was no virtual scaling that could help. This, for me, is the biggest problem with Gitlab hosting: as soon as you hit a scale where a single machine with Omnibus doesn't cut it, the jump in complexity, cost, and engineering hours is significant.
Omnibus is like entry level. We paid for GitLab Professional Services and they recommended going to the larger architecture. Since then, we haven’t had issues.
They have their free fast stats tool and you can run your logs through their tool to get statistics and identify hotspots
I'm not sure if this is the right place to ask, but does anyone else still work in an environment where they have to do synchronous version control? It's a nightmare and I have yet to find a decent solution.
To give an idea, this is a proprietary system that is extendable via scripts, but all of the artifacts are exported via XML files where script source is escaped into one XML tag within the metadata. Same with presentation layers, the actual view XML is escaped into one line within one attribute of the metadata file. The "view" xml may be thousands of lines but it is escaped into a single like of the export file so any change at all just shows that line as being changed in a diff. Attempts at extracting that data and unescaping it even seem to present problems because when the XML is exported often times the attributes within the schema are exported in a different order, etc.
For a company that (optionally) wants to self-host stuff, I'd say GitLab is pretty great - it's there for you, be it in the cloud or on-prem and mostly works, if you have enough resources to throw at the instance.
At the same time it won't always have full on feature parity with some of the other options out there, or won't be as in depth as specialized software (e.g. Jira / Confluence) BUT everything being integrated can also be delightfully simple and usable.
I will say that I immensely enjoy working with GitLab CI at work (https://docs.gitlab.com/ci/), even the colleagues on projects using Jekins migrated over to it and seems like everyone prefers it as well, the last poll showing 0 teams wanting to use Jenkins over it (well I might later for personal stuff, but that's more tool-hopping, like I also browser and distro hop; to see how things have changed).
However, it was a bit annoying for me to keep up with the updates and the resource usage on a VPS so that's why my current setup is Gitea + Drone CI (might move over to Woodpecker CI) + Nexus instead of GitLab, and is way more lightweight and still has the features I need. Some people also might enjoy Forgejo or whatever, either way it's nice to have options!
I like using it at work. I probably would use something lighter if I ever move off github though, as I've seen the IT throw more and more resources at it for simple usage with just 30-40 MRs per day.
Also the free version doesn't have PR requirements or multiple reviewers etc.
One interesting point of GitLab for me is the self-hosted version, including the AI features (Duo) that can also be self-hosted and you can bring your own OpenAI/Anthropic key.
My biggest annoyance with gitlab is that the UI is one huge block of text on white background with absolutely no distinction between user content (like commit messages) and the interface itself, plus you have action buttons buried in the middle of the page.
And everything loads asynchronous causing blocks to dance around when the one above loads …
I also like it. At one point I had my team move all of our team management to it as well. It was a little bit painful as first, but once you understand the issue, epic, milestone hierarchy it was it was great. The board feature that does kanban was cool. Switching from dedicated ec2 runners to pods in our cluster was less awesome…
We use self-hosted GitLab at work. It’s really a pleasure to use, everything works the way it feels like it should. The main downside is the system resource requirements are absurd considering at any given time there’s only 1-2 people using the GitLab interface.
Yeah I started using GitLab for the same reason and also that FSF "approved" of its CE version. But doesn't hosting private repos on GitLab and using public repos on GitHub just give GitHub that much more monetizable value?
It does, and I've even had Gitlab as the primary repo for some time. But if your projects pick up any steam, github mirrors are going to pop up whether you run them or not - I've had people mirror my projects onto github because it means less questions for them when they want to package them for their organisation or minor packaging system than pulling source from "not-Github". Of course, the license allows them to do that, and they're upfront why they're doing it, but if there's going to be a github mirror anyway, may as well have it official.
Also if we're being honest, despite Gitlab being the #2 platform, you're going to get less contributions than on Github as people just aren't going to want to sign into a second service. Now most of my public projects are like "I made this, I put it here to show off, and use it if you like" so if people _don't_ use it, it's no big deal for me, but if you're in it for revenue or clout or just like seeing usage numbers going up, it's clearly not the optimal choice.
It is quite annoying of the lock in. I prefer using GitLab for private projects but it means if I want to FOSS those I now need to support two different platforms to have FOSS projects and my own stuff
But they have a massive backlog and they seem to be focusing their development resources on customer requests, obviously. So it could definitely use improvement.
When I was at a large financial news company circa 2018, we were fully bought into developing in public on github. (they still are to a lesser extent)
The problem is that organising it on github was really really hard. Trying to find and group projects was notoriously difficult and the CI/CD offering was shit.
I joined a startup and it was on gitlab. The server was hosted by the runner was local. We could make arbitrary projects and CI/CD was a dream. Very simple but powerful.
The downside was at the time, it was offline every other week. However to administer, it was far far easier.
Github has improved, you can have organisations and chain them together. But its a motherfucker to administer. They move everything about monthly, and make it very difficult to work out which child org has which power.
The CI/CD has vastly improved, we have private runners. But.
They are really nasty to administer and monitor, and the language you use to make jobs is not that intuitive. It doesn't feel like a shell script with a docker wrapper.
If I had a choice, I'd move us over, but its a lot of faff, and we have so many work arounds.
> testing the CI/CD script on gitlab. It doesn't exist, and it's hell.
Did you try the pipeline editor? It's at <project_url>/-/ci/editor
You can see how GitLab expands the code, validate it (syntax), validate it against a branch (i.e. what happens when I get a push on main), and visualize the full YAML spec of what you have in the editor.
I have that problem with GitHub at the moment because we're switching from self-hosted GL to GH due to company policies, and for me it's much less readable (but I also know I've been playing with it ~1 month so far instead of the 7+ years I spent on GitLab, so need to learn tools etc).
Yeah, my experience on testing GitLab CI/CD script logic is to use a sacrificial branch and grind through test commits until it works, then Squash commits when merging back into main branch.
It's so sad that we can't just run local validations on the CI/CD script through a local emulator. If they had a local emulator approach similar to what is provided by Firebase for their cloud products, that would be amazing.
Did you give https://gitlab.com/RadianDevCore/tools/gcil a try yet? The developer has been a pretty long record of maintaining the project and it allows you to get some level of debugging locally before pushing.
Social issues make gitlab better although there are also social downsides.
The people who submit fake/AI issues and PRs for resume purposes seem to exclusively use github and this is a substantial expense for the real users (see the recent Curl discussion). Gitlab doesn't have those people (or at least its a wildly smaller problem).
One social downside is noobs will insist a project does not exist if its not on github, even if you send them the gitlab URL. Almost have to physically cut and paste the gitlab URL into their browser for them before they will believe. You can either do nothing which filters them, not a bad idea, or create a clone or placeholder on GH that basically links back to the real repo on GL. I don't know if that is allowed in the ToS for GH but people certainly do it a lot.
It's okay. But I would definitely pick Forgejo over it for self-hosting these days. It's written in Go which is a lot better. Much faster, easier to set up, you can actually follow the code (sometimes I've had to read Gitlab's code to understand features and nearly always failed). Also no features are paid. The ones that made us eventually pay for Gitlab were mandatory reviews and merge trains. Tbh I don't think Forgejo has either of those features yet but at least when they are available they'll be free!
Both of the headline sentences on the home pages tell me they’re self-hosted.
They both also have cloud options, one focussing more on large scale and features I don’t care about, the other others some sort of hosted instance that’s private.
I’ve liked using GitLab but it’s definitely felt like their IPO lead to more chasing flash and less attention to quality. They yanked the support rep which customers used to get–everything goes through sales now–and started putting most features behind the hefty Ultimate price tier, and there are so many cute features which need more polish but since they’re not “AI” it seems like they’re ignored even though they have open issues with years of customers saying they have the same problem.
This has lead to a game: each time the sale pitch claiming big wins for their AI tools arrives, ask “when will we start seeing GitLab development back to pre-IPO speed?”
Nah, they were always chasing flash. I enjoyed using their products circa 2015-2020, but man they really leaned into the Pareto Principle. Every feature had rough edges, and they didn’t invest much in polish.
It’s a tough trade-off for a small team competing with a behemoth, and I guess their success indicates that they played their hand correctly. If you are going for the enterprise segment then checking off the feature requirements can be more important than making each feature perfect.
Gitlab’s CICD offering is way more robust than Github Actions.
I don’t think it was perfect back then either but it felt like it got worse. I think this may prove a strategic error: checking all of those enterprise boxes gets you in the door but they don’t have Microsoft’s clout in that market and depend on technical staff pushing for them over GitHub.
~2400 vs ~5600 isn’t “small team vs. behemoth”.
They were nowhere near 2400 in the time range I mentioned.
>Speed. The GitLab web interface has always felt sluggish to me.
10 years later the same problem remains. While Gitea / Forgejo have very little performance problems. And will only get better once Go 1.26 is out. Which is a much bigger release than a single digit version number upgrade.
I used GitLab only as a remote repo for private projects, no CI at all. The laggy interface and that damn browser check every so often made me close my account.
It must be a fundamental architectural problem with Gitlab. When I had to use it for work the speed killed me. Especially searching for issues. I will never consider gitlab for anything until they find a way to boost performance.
The Ruby on Rails tax. It isn’t impossible to make snappy apps with it, but it must be uneconomical in terms of dev costs because no one does.
While there is indeed a Ruby on Rails tax, Github is also written in Rails as well (https://github.blog/engineering/architecture-optimization/bu...)
So is Shopify and Stripe. They can scale.
These days, if I want something that has some of the ergonomics of Rails in a platform I know can scale better than Ruby, I reach for Elixir/Phoenix.
Github can get pretty sluggish as well; if you have a pull request with lots of comments page loads begin to take a dozen seconds or more. AI code review bots make it painful for humans to use it.
I dont think that is true, consider Fuzzy, Hey, Basecamp, Shopify all seems to be doing fine. Shopify actually got impressively fast in the recent two years I have no idea why. Github used to be fast as well.
So while Go by default will always be faster then Ruby Rails, there are plenty of examples of decently fast Ruby Rails Apps. Having 10 years saying they will improve performance and not getting any of it suggest problems with Gitlab itself more than RoR.
> consider Hey, Basecamp, Shopify
Basecamp is slow as hell, Shopify depends on some insanely specific tuning, and I don't use Hey but it's the same team as Basecamp IIRC.
> The Ruby on Rails tax.
Yeah, from my experience administering a pretty small self-hosted instance, I think it's got to be this. Every single admin action you try to take on the backend is SLOWWWWW. Restarting the services takes a few minutes. Just to bring up an admin console on the server in a CLI takes well over a minute, which indicates a tremendous amount of overhead purely on the ruby side.
There's just something fundamentally slow about how it's all put together. I wouldn't blame the language or tech stack, exactly - but perhaps Ruby on Rails is not a great fit, anymore, for a fully featured forge of this scale?
Foreman is a great piece of software for host configuration management.... except for the fact that it's written in Ruby. It takes like 3sec to load the parameters page, and for that reason, it should never be used.
Very weird, my experience is the opposite. When changing jobs in 2018 I moved from Bitbucket and Confluence (own data center, but to my understanding powerful and well-maintained) to Gitlab cloud. Atlassian was laggy, overengineered and not pleasant to use. Gitlab was slim and fast. They have added a lot of stuff since then and maybe smreponsiveness has suffered a bit, but I can't really complain. Gitlab works well most of the time. Recently I have had to use Jira cloud. Much worse than Gitlab. Could be that our templates are overloaded and some extensions are particularly bad (looking at you XRay). But pretty sluggish and annoying user experience. With Gitlab over-excited managers cannot ruin performance by having more and more details added to the templates.
jira, bitbuck, etc historically and currently are all slow(still faster than they used to be, considerably so). So in comparison to a set of tools I have always seen talked about as slow, gitlab is faster.
Just like a truck will always be more sluggish than a small car. They are very different beasts where one is aimed at enterprises and the other one for small projects without all the corporate needs.
A truck is sluggish because of its weight and inertia. It’s a law of nature. What law of nature is making Gitlab slow?
The enterprise version is just as slow.
I thought they're only struggling with the free public version, but no. GitLab run on a private box is the same bag of lags and loading spinners.
I'm not talking about GitLab enterprise vs. GitLab free. It's about GitLab vs small projects like Gitea / Forgejo mentioned in the parent comment.
"It's enterprise" it's such a lame excuse, IMO. There shouldn't be a speed tax, especially if you aren't using the "enterprise" features. We need to stop making excuses for bad software. It's 2026 we have insanely powerful computers, why should I have to wait to get the result of searching a few text-only issues or display a diff?
Yea, I run my own gitea in the basement proxmox box to have a decent performance. Page load times are <30ms
Curious, why not use docker?
I like LXC containers and how they integrate with PBS.
Simply having CI/CD enabled causes GitLab to use most of one CPU core... forever. It's astonishing.
> And will only get better once Go 1.26 is out.
Can anyone tell me why? What's changing with Go 1.26?
Go 1.26 Is Around the Corner: Small Changes, Big Impact for Real-World Go Systems
https://medium.com/@anand.hv123/go-1-26-is-around-the-corner...
https://freedium-mirror.cfd/https://medium.com/@anand.hv123/...
I just wish they had sub/project folders like in gitlab. I would switch in a heartbeat.
I've been using GitLab since the early days, but a week ago I switched to Forgejo. Power usage on the server dropped by 10%, despite both being idle most of the time.
As the author says, GitLab feels sluggish, and is bloated with 1001 thing I'd never use that just makes the UI a pain. Despite all the features I don't need, some that I would benefit from are disabled in the free version.
Forgejo is simpler. It allows me to hide features per project that I don't need. Bit there are some tradeoffs. Updates on GitLab was great. I've been letting it self update for years with no issues. This does not work on Forgejo. Forgejo is also a lot less polished, and some features just doesn't seem to work like they should.
Tangent, but fantastic website. Honestly it was a pleasure just to read it and click around on it. I'm not sure if the design and idea was your own or part of some Jekyll theme, but the execution is just fantastic. Couldn't find the source in your GitHub repos, but maybe I just didn't look hard enough.
It's also one of the few instances where the dark theme is pleasantly readable.
agreed. execution of the idea is tasteful.
who thought showing markdown as markdown could be cool :)
Seconded, this is a phenomenal personal website.
I switched from GitLab to Forgejo for my private projects after not wanting to deal with how slow GitLab's interface is anymore.
I still have proper CI, issue tracking, and all other features I care about, but the interface loads instantly and my screen isn't filled with many features I'll never use for my private projects.
I came here to say this. I switched to forgejo after self hosting gitlab for years, and haven't missed anything.
The article mentions the container registry as a prime feature of gitab. Forgejo has this, btw.
In addition, speed (of everything) is so good with forgejo. The resource requirements (napkin math, but...) are 10% of gitlab.
I see no reason to ever use GitLab again.
There are two minor annoyances for me, but not deal breakers. . First, I actually prefer the GitLab CI syntax. "GitHub Actions" is a mess. I suppose it makes sense to use the dominant gorilla (github actions), but converting to this CI was more trouble than it should have been.
Also, the forgejo API: it is much less developed. I did like exploring with GraphQL which is totally missing in forgejo. But, you have access to the database directly (and can use sqlite or postgres, your choice) so you can really do whatever you want with a custom script. Forgejo API and their infrastructure around it is just a bit more clunky, but nothing that was a major problem.
One of the reasons I like how lightweight GitTea/Forgejo is allows me to develop with argocd locally. Spin up a kube cluster with tilt, bootstrap forgejo, bootstrap Argo and point it at forgejo, now I can test Appset devs with sync waves locally
Is there any point to switch to Forgejo for my open source projects? Wouldnt I just be leeching resources from the guys at Codeberg/ whereever instead of Microsoft?
Codeberg _wants_ to host open source projects; it isn't leeching any more than adding articles to Wikipedia.
If you feel guilty, you can self-host Forgejo, contribute to Forgejo, or become a Codeberg member and pay them a yearly fee of your choosing (https://join.codeberg.org/).
Just tried it out for a bit, and it looks great and is super snappy. It seems the CI portion is delivered by a project Woodpecker? How does this work and is compared to gitlab CI?
Forgejo has an integrated CI/CD solution, Forgejo Actions [1], that is very similar to GitHub Actions (and thus not so similar to GitLab CI). This is what you'll probably use if you self-host.
Codeberg (a public Forgejo-based forge) also offers Woodpecker CI. Their hosted Forgejo Actions is still in beta AFAIK, but you can also use your self-hosted runners.
[1] https://forgejo.org/docs/next/user/actions/quick-start/
Forgejo's code review tool slavishly follows GitHub (like a lot of other things it does) and so has the same inferior developer workflow that comes with that.
GitLab is no Gerrit, but it does at least support stacked MRs, and at least seeing comments between forced pushes / rebases, if not tracking them.
I use Codeberg, and therefore Forgejo for my open source project, but frankly the GH style workflow is not appropriate for serious software development. It forces one to either squash all commits or use <gag> merge commits. Many people have developed stockholm syndrome around this and can't imagine any other way. But it sucks.
The GH model encourages big-bang giant PR all at once development, and it's corrosive on productivity and review culture inside teams. And it leads to dirty commits in the git history ("fix for review comments." "merge." "fix for review comments." etc)
I worked with GitLab for a year and a half on a job, and I prefer its review tool for functionality, though not necessarily UX.
Here's a link to a previous HN discussion on forgejo
https://news.ycombinator.com/item?id=42753523
I didn't know people disliked GitLab. I use it for work and while some things could definitely be improved, overall I find it to be a pretty intuitive and easy experience. They could definitely improve user management at the admin vs group level (you cant see LDAP sync settings in admin panel, you have to navigate to the group) but overall I don't get frustrated using it. It's CICD syntax is a breeze for the most part too
> It's CICD syntax is a breeze for the most part too
Hard disagree. Gitlab CI, while more powerful than some alternatives, is so so bad, its YAML-based syntax included. As I said in another thread[0]:
> 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.
[0]: https://news.ycombinator.com/item?id=46296816
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.
Same experience, GitLabs CI/CD language is to me so much better - it has really strong abstractions and you can model a lot of developer experience into it. Especially when it comes to security practices of GitLab CI, but also custom runners, web terminals, ... there is just so much that is shining much more than any other Git forge with built-in CI/CD.
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.
Well, I have used a lot of Github Action too, and Gitlab is by far easier to do fairly complicated stuff with, but Github Actions has much better re-usability if you need to re-use or share parts of the job with all projects you build.
GitLab is now getting steps and has components.
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
Agreed. As the saying goes,
> every sufficiently complex CI system becomes indistinguishable from a build system.
But what alternatives are there that also integrate well with version control systems like GitLab/GitHub/Gitea/…?
For instance, Dagger works quite well but its UI is going to be completely separate from whatever CI system you're using.
the pattern I recommend is to use CI system only at the event trigger layer e.g. setting up invocation as a response to webhooks. Then you drop down into whatever orchestration layer you implement yourself to do the actual work. So in my configurations, the ci yml is very minimal, it essentially says "set up env vars, inject secrets, install minimal deps and invoke `ci` command of whatever adult system you so choose" (Dagger would be one example).
What UI are you looking for outside of log streaming? If you want to see a DAG of your workflows and their progress you can use other systems as you say (Dagger has this), or your orchestration layer can implement that.
If you want to use the orchestration component of your ci tooling, you always can do so, and get your DAG viewer, but you have to accept all of the constraints that come with that choice
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?!
I didn't mean to say I changed the pipelines on the daily, though admittedly I did have to touch them rather frequently since we were migrating stuff away from Jenkins.
I dislike the UI a lot. I find it very confusing.
Github is so much easier to use. I don't understand why gitlab wants to make everything so complicated.
Honestly for me Github is really confusing. In Gitlab if I want to see a list of commits, I click on commits, for branches I click on branches, issues on issues, etc. . On Github there are Issues as a toplevel thing, but for commits I need to click a weird history button on the project homepage. Traversing and querying commits is so complicated that I often just give up and clone the project instead.
> Feature overload. GitLab tries to be everything.
This is the primary reason I dislike GitLab. It is so complicated to use.
Github issue trackers are so simple to use.
Perhaps GitLab offers more features for project owners, but as a user, I much prefer github. Of course I'd prefer it even more if Microsoft wouldn't control github ...
Same, also the features are poorly implemented.
This is due to the fact that they don’t well.
Same. We used to host a GitLab instance in our enterprise. As a sysadmin that used that only occasionally, let me tell you, it took me a hundred times the time to figure out how to do something than actually doing it.
Even just finding the source code or issue tracker was like hidden behind layers of layers in the navigation.
No we're hosting GitHub. Shits never been easier. GitHub also has its ugly sides, but the ugly sides still are better than anything in GitLab.
I hate GitLab with a passion.
> The 10GB limit per project sounds small on paper but I’ve never come close to hitting it
The docker images don't have limits, there is a limit per layer. IIRC I've distributed a 100GB image through their free tier (just had to make sure to keep the layer size small enough).
Update: Sources
https://docs.gitlab.com/user/storage_usage_quotas/ https://gitlab.com/gitlab-org/container-registry/-/issues/10...
Has someone made a p2d yet where they split a 4K movie into a bunch of docker layers to push and pull through an OCI registry? I have a 70GB REMUX copy of Interstellar that I'd love to docker push to gitlab.
Yeah, I mean thinking about it - you could also just use HN to host that image. I believe gdrive et al would just do the job.
Unlimited size, unlimited push / pull for free as long as the layers are under 10GB? Is that the correct take away?
yes, and as long people don't start exploiting that.
While it‘s pretty great to have such a unified interface, there are many papercuts. To me it has become a bit of a meme that you always end up in this old-issue flow: I want to do X -> Try it -> Run into an issue -> Search for solution -> Find an official bugreport that is 3-8y old. Also many features seem to be stuck in either the 80/20 hell or it the „we needed a bulletpoint on a feature list and built a barely working MVP“-situation. The slow interface, as mentioned in other comments, is so incredibly painful on MR-views that it drives me crazy some days.
> To me it has become a bit of a meme that you always end up in this old-issue flow: I want to do X -> Try it -> Run into an issue -> Search for solution -> Find an official bugreport that is 3-8y old.
That's been my experience as well and, in fact, it was totally a meme at my former client! See also my comment in another recent thread: https://news.ycombinator.com/item?id=46296816
We switched to gitlab at work about five years ago and this perfectly summarizes my experience. Add to that Gitlab projects also have a included Maven, NPM and python compatible package registry, so you can just push your package back in the CI pipeline is one of my favourite features as a smaller team. My least favorite feature is actually the sheer number of features. There is actually too many features. And the constant waiting. Basically every screen is just twice as slow as I would like to wait.
After using Stash for ages at work we switched to gitlab which was refreshing. It was fast, self hosted, and full of features, especially useful around quality gates and build on PRs. Then it was decided we should go for best of suite instead of breed and we went to azure devops.
It is slow as molasses, issues are more project management oriented instead of coding, quality gates are virtually non existent and builds are now slow. Builds are slow because instead of our beefy build servers they run on VMs, that are undersized and have IOPS restrictions, because downloading the cache for maven/docker/npm is relatively fast but actually expanding it on disk is slow, because just the simple orchestration to spawn a job is also slow.
I would love to go back to gitlab and I would even dedicate some time to performance tune it and contribute back. I think gitlab does everything right. (Technically, not sure about pricing and tiering.)
Forgejo does all that while being lightweight and run by a non-profit. Gitlab is awfully resource hungry.
> Gitlab is awfully resource hungry.
Yes... and no.
Gitlab doesn't make sense for a low-volume setup (single private user or small org) because it's a big boat in itself.
But when you reach a certain org size (hundreds of users, thousands of repos), it's impressive how well it behaves with so little requirements!
Forgejo scales too, even for a large org it's a perfect choice.
GitLab is about to tank in quality hard. Completely new leadership team in the last 6 months, IYKYK
Give it 1-2 years, feature quantity will take precedence over feature quality
If you log into your GitLab account from a Hong Kong IP address, they'll delete your account after 60 days and tell you to use JiHu, a Chinese company, instead.
Never understood why I get the weird looks if I tell people that I use GitLab. Like CICD is really good and lots of useful features are free.
It was once a cool alternative to gitlab. Self hostable, open source, etc... Now it's bloated hell. Everything from source control, to project management. I don't have good experiences with it in recent years
For a long time I self hosted Gitlab, and was always quite happy with it, but I recently moved my VPS and decided to give Forgejo a try, and I have to say it's refreshing. It's really fast and takes a fraction of the resources Gitlab does. I'm sure Gitlab have more features, but frankly, I wasn't using them. I still like Gitlab, we use it at work and it does a good job, but for my own needs I don't see myself switching back any time soon.
It's frustrating that the so-called enterprise solutions are monsters. In a former workplace we were using Gogs for a long time. It's so nice to work with software that doesn't require a ton of resources for a relatively simple task.
We are running GitLab Ultimate in three different environments. Like 2000 users each and each user pipeline runs crazy like hundreds amounts of jobs. GitLab is keeping up. But we are sized for the 40 RPS architecture
> But we are sized for the 40 RPS architecture
Just in case anyone else (like me) didn't get the reference:
> This page describes the GitLab reference architecture designed to target a peak load of 40 requests per second (RPS), the typical peak load of up to 2,000 users, both manual and automated, based on real data.
https://docs.gitlab.com/administration/reference_architectur...
We used to run Gitlab Premium for around 300 users running hundreds of jobs over some monorepos. Gitlab suggested a small architecture using Omnibus, and while it helped a bit, it didn't perform as well under load as we expected it to.
Eventually, there was no virtual scaling that could help. This, for me, is the biggest problem with Gitlab hosting: as soon as you hit a scale where a single machine with Omnibus doesn't cut it, the jump in complexity, cost, and engineering hours is significant.
Omnibus is like entry level. We paid for GitLab Professional Services and they recommended going to the larger architecture. Since then, we haven’t had issues.
They have their free fast stats tool and you can run your logs through their tool to get statistics and identify hotspots
My experience also.
I would never use Gitlab for my own needs, but at company level, it's impressive how well it behaves!
I'm not sure if this is the right place to ask, but does anyone else still work in an environment where they have to do synchronous version control? It's a nightmare and I have yet to find a decent solution.
To give an idea, this is a proprietary system that is extendable via scripts, but all of the artifacts are exported via XML files where script source is escaped into one XML tag within the metadata. Same with presentation layers, the actual view XML is escaped into one line within one attribute of the metadata file. The "view" xml may be thousands of lines but it is escaped into a single like of the export file so any change at all just shows that line as being changed in a diff. Attempts at extracting that data and unescaping it even seem to present problems because when the XML is exported often times the attributes within the schema are exported in a different order, etc.
For a company that (optionally) wants to self-host stuff, I'd say GitLab is pretty great - it's there for you, be it in the cloud or on-prem and mostly works, if you have enough resources to throw at the instance.
It's not as demanding as a some of the other software out there, like a self-hosted Sentry install, just look at all of the services: https://github.com/getsentry/self-hosted/blob/master/docker-... in comparison to their self-contained single image install: https://docs.gitlab.com/install/docker/installation/#install...
At the same time it won't always have full on feature parity with some of the other options out there, or won't be as in depth as specialized software (e.g. Jira / Confluence) BUT everything being integrated can also be delightfully simple and usable.
I will say that I immensely enjoy working with GitLab CI at work (https://docs.gitlab.com/ci/), even the colleagues on projects using Jekins migrated over to it and seems like everyone prefers it as well, the last poll showing 0 teams wanting to use Jenkins over it (well I might later for personal stuff, but that's more tool-hopping, like I also browser and distro hop; to see how things have changed).
However, it was a bit annoying for me to keep up with the updates and the resource usage on a VPS so that's why my current setup is Gitea + Drone CI (might move over to Woodpecker CI) + Nexus instead of GitLab, and is way more lightweight and still has the features I need. Some people also might enjoy Forgejo or whatever, either way it's nice to have options!
I like using it at work. I probably would use something lighter if I ever move off github though, as I've seen the IT throw more and more resources at it for simple usage with just 30-40 MRs per day.
Also the free version doesn't have PR requirements or multiple reviewers etc.
One interesting point of GitLab for me is the self-hosted version, including the AI features (Duo) that can also be self-hosted and you can bring your own OpenAI/Anthropic key.
But only with a premium subscription, right?
Yep, you need a subscription to use your subscriptions.
My biggest annoyance with gitlab is that the UI is one huge block of text on white background with absolutely no distinction between user content (like commit messages) and the interface itself, plus you have action buttons buried in the middle of the page. And everything loads asynchronous causing blocks to dance around when the one above loads …
> My biggest annoyance with girls
Pardon?
I also like it. At one point I had my team move all of our team management to it as well. It was a little bit painful as first, but once you understand the issue, epic, milestone hierarchy it was it was great. The board feature that does kanban was cool. Switching from dedicated ec2 runners to pods in our cluster was less awesome…
We use self-hosted GitLab at work. It’s really a pleasure to use, everything works the way it feels like it should. The main downside is the system resource requirements are absurd considering at any given time there’s only 1-2 people using the GitLab interface.
Yeah I started using GitLab for the same reason and also that FSF "approved" of its CE version. But doesn't hosting private repos on GitLab and using public repos on GitHub just give GitHub that much more monetizable value?
It does, and I've even had Gitlab as the primary repo for some time. But if your projects pick up any steam, github mirrors are going to pop up whether you run them or not - I've had people mirror my projects onto github because it means less questions for them when they want to package them for their organisation or minor packaging system than pulling source from "not-Github". Of course, the license allows them to do that, and they're upfront why they're doing it, but if there's going to be a github mirror anyway, may as well have it official.
Also if we're being honest, despite Gitlab being the #2 platform, you're going to get less contributions than on Github as people just aren't going to want to sign into a second service. Now most of my public projects are like "I made this, I put it here to show off, and use it if you like" so if people _don't_ use it, it's no big deal for me, but if you're in it for revenue or clout or just like seeing usage numbers going up, it's clearly not the optimal choice.
It is quite annoying of the lock in. I prefer using GitLab for private projects but it means if I want to FOSS those I now need to support two different platforms to have FOSS projects and my own stuff
I also like it. Been using it since around 2013.
But they have a massive backlog and they seem to be focusing their development resources on customer requests, obviously. So it could definitely use improvement.
The only thing I currently miss is allowing me to use my own sub-domain for their Docker registry.
I'm also using GitLab for personal projects. Works well enough.
When I was at a large financial news company circa 2018, we were fully bought into developing in public on github. (they still are to a lesser extent)
The problem is that organising it on github was really really hard. Trying to find and group projects was notoriously difficult and the CI/CD offering was shit.
I joined a startup and it was on gitlab. The server was hosted by the runner was local. We could make arbitrary projects and CI/CD was a dream. Very simple but powerful.
The downside was at the time, it was offline every other week. However to administer, it was far far easier.
Github has improved, you can have organisations and chain them together. But its a motherfucker to administer. They move everything about monthly, and make it very difficult to work out which child org has which power.
The CI/CD has vastly improved, we have private runners. But.
They are really nasty to administer and monitor, and the language you use to make jobs is not that intuitive. It doesn't feel like a shell script with a docker wrapper.
If I had a choice, I'd move us over, but its a lot of faff, and we have so many work arounds.
These days I see a lot of projects move to Codeberg, like Zig for example. Interesting to see how these product offerings will evolve over time.
Another interesting choice of GitLab's CI is to effectively display `head -c N` of the logs instead of `tail -c N`.
Some builds produce a lot of output, and Gitlab simply truncates it. Your job failed? Good luck figuring out what went wrong :)
Showing the last N bytes makes so much more sense as a solution to the artificial problem of CI output being too large.
Um, no? It does a tail.
I'll add one more annoying part: testing the CI/CD script on gitlab. It doesn't exist, and it's hell.
Edit: perhaps it's skill issue too, but I'm annoyed they don't have a similar feature to jump to definitions as github does.
> testing the CI/CD script on gitlab. It doesn't exist, and it's hell.
Did you try the pipeline editor? It's at <project_url>/-/ci/editor
You can see how GitLab expands the code, validate it (syntax), validate it against a branch (i.e. what happens when I get a push on main), and visualize the full YAML spec of what you have in the editor.
I have that problem with GitHub at the moment because we're switching from self-hosted GL to GH due to company policies, and for me it's much less readable (but I also know I've been playing with it ~1 month so far instead of the 7+ years I spent on GitLab, so need to learn tools etc).
Yeah, my experience on testing GitLab CI/CD script logic is to use a sacrificial branch and grind through test commits until it works, then Squash commits when merging back into main branch.
It's so sad that we can't just run local validations on the CI/CD script through a local emulator. If they had a local emulator approach similar to what is provided by Firebase for their cloud products, that would be amazing.
Did you give https://gitlab.com/RadianDevCore/tools/gcil a try yet? The developer has been a pretty long record of maintaining the project and it allows you to get some level of debugging locally before pushing.
I like GitLab but hate their pricing. Both as a personal user and a corporate user I'd love to give them money but their pricing is outrageous.
Social issues make gitlab better although there are also social downsides.
The people who submit fake/AI issues and PRs for resume purposes seem to exclusively use github and this is a substantial expense for the real users (see the recent Curl discussion). Gitlab doesn't have those people (or at least its a wildly smaller problem).
One social downside is noobs will insist a project does not exist if its not on github, even if you send them the gitlab URL. Almost have to physically cut and paste the gitlab URL into their browser for them before they will believe. You can either do nothing which filters them, not a bad idea, or create a clone or placeholder on GH that basically links back to the real repo on GL. I don't know if that is allowed in the ToS for GH but people certainly do it a lot.
Maybe it's not applicable for private repos as much but GitLab has had far too many severe security bugs. I wouldn't consider using it.
It's okay. But I would definitely pick Forgejo over it for self-hosting these days. It's written in Go which is a lot better. Much faster, easier to set up, you can actually follow the code (sometimes I've had to read Gitlab's code to understand features and nearly always failed). Also no features are paid. The ones that made us eventually pay for Gitlab were mandatory reviews and merge trains. Tbh I don't think Forgejo has either of those features yet but at least when they are available they'll be free!
Why not Gitea over Forgejo, which is what Forjego seems to be forked from?
That said, looking at recent releases, there are nice things from both, and if I wasn’t running GHES, I’d be stuck to choose between the two
This is gitea's homepage:
https://about.gitea.com/
This is forgejo's homepage:
https://forgejo.org/
---
The homepages should tell you which is more focused on the self-hosted open source use case.
Both of the headline sentences on the home pages tell me they’re self-hosted.
They both also have cloud options, one focussing more on large scale and features I don’t care about, the other others some sort of hosted instance that’s private.
Sorry, doesn’t help me
Philosophical convictions, I guess?
One is supported by a for-profit org, while the other by a non-profit org.
Absolutely the same here. Same journey and same points. One added benefit is that you don't have to suffer through GH actions on GitLab as well.
They sometimes do braindead moves like prohibiting no-expiry-date access tokens but otherwise it's pretty smooth sailing.
And with recent migration to an SPA GitLab feels quicker and quicker.