Goodbye GitLab; Hello Gitea, Nexus and Drone

It is pretty late evening over here and i've been hard at work for the past two days, my entire weekend: first while trying to update GitLab to a newer version from my ancient and neglected instance due to it having some pretty large security problems, but then later while trying to migrate away from it due to a variety of problems with the upgrade:

Overall, i'd say that the migration was a success and not only that, but it lead me to create a few blog posts to walk you through my experiences, even if the first one might appear a bit critical of GitLab. Nonetheless, i think that we should talk more about all of the interesting and curious ways that software can break and how we're likely to run into more situations like that as the complexity grows.

GitLab updates are broken

The gist of my experience was that GitLab is a complicated piece of software and the Omnibus install actually contains a variety of pieces of software, all of which will experience changes across major versions. And, the more changes there are and the further you stray from the happy path of the configuration (even if you only follow the official instructions in how to optimize everything for running with less RAM), the more likely you are to run into problems.

Now, i've written about software complexity previously, but in the end the accumulated issues and how demanding GitLab was in regards to resources simply made me look elsewhere. Of course, i'll still gladly use GitLab at work where ensuring that the instance is up and running successfully is someone else's job, but in my homelab i've since migrated over to a few alternatives.

While there wasn't a single package that would replace all of its functionality in one go, it is now that i realize that i didn't want anything like that all. A few simpler pieces of software that integrate with one another is actually simpler as far as figuring out what might have gone wrong goes, as well as when you need to manage updates, configuration and resource usage of each individual component. Plus, there's definitely an argument to be made about striving towards simplicity and having everything be a little bit more decentralized, without the complexity that maintaining all of GitLab's components manually would entail.

I actually wrote an article that talks more in detail about the problems that i ran into while attempting the update: GitLab updates are broken

Moving from GitLab to Gitea

Gitea turned out to be a really good replacement for GitLab for my personal needs. If it's simplicity that you're after, it's hard to beat a piece of software that comes packaged as a single binary and can run off of SQLite (or external DBs, depending on your scaling needs). Not only that, but it feels far less brittle than an Omnibus install of GitLab, even when you look at the everyday operation and how snappy everything is.

I actually wrote a separate article for this: Moving from GitLab to Gitea

Moving from GitLab Registry to Sonatype Nexus

In comparison, Nexus felt like an evil, but the necessary kind, since i haven't found anything better than it out there. It does guzzle RAM much like GitLab does, however at the same time it is pretty much the universal one stop solution for all of your repository hosting needs, be it a Docker Registry, a Maven, NuGet, pip, npm or another type of repository. It's actually amazing how much useful stuff you can fit inside of a single software package (that you can still purge specific blob stores from if it begins misbehaving):

I actually wrote a separate article for this: Moving from GitLab Registry to Sonatype Nexus

Moving from GitLab CI to Drone CI

Drone is a package that i have almost nothing but good things to say about. It not only does what you'd expect from it and does it really well (the docs organization could be a bit better, but they're there, they're sufficient and both its UI and UX are excellent), but is also container native and similarly lightweight to Gitea. Speaking of which, the two integrate rather well and provide a good experience.

I actually wrote a separate article for this: Moving from GitLab CI to Drone CI

Some thoughts after the migration

But this article isn't here to be a retelling of everything that i did. Rather, i'd like to sum up the whole experience with the following: "For my circumstances, it was worth it."

GitLab isn't a bad piece of software. Sure, it sometimes has passionate followers who blow its ease of use out of proportion, as an image near the end of the broken update post points out, but when you have someone to manage it (for example, a self-hosted instance inside of an organization) or even when you're using the cloud variety, it's still one of the better solutions out there. I still think that GitLab CI is actually more comfortable to use than GitHub actions (even thought they're getting there).

It's just that not all software is suited to all circumstances. For a while, i thought that running GitLab both at work and at home would let me learn skills and carry them over. I was actually right in that regard, but at the expense of the homelab (or personal cloud) instance being comparatively slow and also a bit cumbersome sometimes - especially when the default configuration hides the storage locations for your container images and other packages from you or at least takes digging around the configuration to customize.

Also, not to say anything bad about Ruby on Rails, but the choice that they made towards being able to iterate on features quickly and provide an amazingly rich feature set also came at the expense of making it all a tad slower and more resource intensive, which really shows when compared to how quickly Gitea seems to run. Of course there are features that Gitea doesn't provide, but what's there is still wonderfully pleasant, especially for a private instance or one with just a few users.

Curiously, after the migration the total resource of the server didn't actually go down that much, maybe i got a hundred megabytes or so of free RAM back:

But even so, a lot of it was about how much resources each individual package would need, as Gitea and Drone are now not dragged down by a set of historical constraints or other tradeoffs, like GitLab is:

(the tool that's pictured here is ctop, in case anyone is wondering)

Summary

A lot of the software out there in the industry is about tradeoffs and you definitely shouldn't be afraid to experiment with different solutions to find whatever is the most comfortable option for you. Sure, sometimes it might take a lot of time to do migrations like these, since by now i've spent my entire weekend on this, but it's been a pretty nice learning experience and i hope some of it is useful for other people!

Also, something else that i just now realized was that my GitLab instance was so out of date, because updating it was a painful process - the data directories that i'd need to manually back up (in addition to automated backups which are done every other day) before an update would take a lot of space, the container images are large and download slowly, the changelogs are long and configuration changes plentiful (the Unicorn to Puma migration comes to mind) and as my other post shows, a lot can go wrong and it be a very frustrating process.

In short: if you want your users to update more often and stay safe, make updating an easier and less scary process. Of course, in the case of GitLab, i don't think that's something that's necessarily easy to do, since their Omnibus install is about as close as you can get to that, but even that had problems, at least in my particular case. Sometimes you just need an alternative or a few other pieces of software to do more or less the same thing, and that's okay.