Migration to Forgejo

Our GitLab infrastructure is on its way out, in favor of a leaner, more friendly customized Forgejo instance. Find out what this will mean for you and the reasons why.

Migration to Forgejo
Unrelated: Kitties. I mean just look at them. Photo by Quan Jing / Unsplash

Our GitLab infrastructure has been retired, in favor of a leaner, more friendly customized Forgejo instance.

Forgejo is a self-hosted, lightweight software forge. It is based on Gitea, from which it is forked due to Gitea's sudden change of ownership of domains and trademarks against the community's consent. You can read Forgejo's own comparison with Gitea document here.

Initially, we started using GitLab because that was the first Git server I ever truly tried running on my own, years ago. I never could because my server (a tiny DigitalOcean droplet) was far too weak. I decided, for Ryubing, let's get a capable server and let's run a GitLab. It felt like every Switch emulator fork used Gitea (or a derivative such as Forgejo) anyways, so it'd be doing 2 things: set us apart from the rest and I'd be finally running a GitLab like I had always wanted.

I genuinely really like GitLab's UI, but the #1 complaint I hear from people (contributors included) is that they hate it. This has not gone unnoticed; I don't want to maintain a system that sucks to contribute on.

Additionally, I've heard reports of comments on issues/MRs simply infinitely loading. One of our contributors has never once seen a comment. Which is a problem considering they're a contributor.

The catalyst for doing this was the realization that I cannot change instance settings anymore; they all fail with the same cryptic error:

Application Settings Update Failure with Cryptic Error Message
Modification of any setting in the admin area results in this error.

This is frankly not acceptable. We cannot have a Git server where settings are immutable.

So then, I made the decision. This is the straw that broke the camel's back; not even GitLab refusing to renew our Enterprise Edition OSS license was as annoying as not being able to change settings.

All that being said, we will be much better off on Forgejo. Forgejo's native CI system, Forgejo Actions, is "familiar" to GitHub Actions. It's the same workflow syntax, many of the same pre-made actions work (such as actions/checkout, and many more). This means that our existing CI workflows will work, once we've made the necessary changes to account for the differences in available software on the runners, or the APIs they're running against. We've already got canary building on our own CI infrastructure!

The GitLab instance will not be going offline immediately. It is currently, and will continue to be accessible until June 1st 2026, at https://legacy.git.ryujinx.app/explore. Avoid visiting the root (i.e. legacy.git.ryujinx.app), as that redirects to git.ryujinx.app as if it was a GitLab instance. I cannot change it to legacy.git.ryujinx.app on account of the immutable settings issue I described above.

The Update Server has already been modified to account for an entirely different version cache backend. GLI has also been updated to v3, removing much of our old GitLab-specific release flow logic and replacing it with a leaner Forgejo alternative (leaner, since GLI doesn't need to handle asset uploads anymore).

When the migration is done, it should hopefully be like we were always on Forgejo to the non-contributor end-user. The only way this won't be the case is old builds that link to changelog URLs on git.ryujinx.app as a GitLab host.

Me when the settings UI broke.