157 lines
6.6 KiB
Plaintext
157 lines
6.6 KiB
Plaintext
---
|
|
title: "Summary of Free Self Hosted Git Options"
|
|
author: "James Pace"
|
|
date: "2024/01/12"
|
|
---
|
|
|
|
# Introduction
|
|
|
|
A few years ago I set started setting my own self hosted
|
|
development stack [^dev-stack-defintion] at home in Kubernetes.
|
|
Particularly, I currently self host gitea, a server hosting apt and
|
|
rpm repositories, a CI stack built with Tekton, and a container registry.
|
|
This article will focus on why I chose to self host anything at all,
|
|
why I chose to self host a git forge specifically, and why I chose
|
|
Gitea from the different options on the market.
|
|
|
|
# Why self host a git forge?
|
|
|
|
Cloud hosted development stacks like Github and Gitlab are extremely popular and
|
|
are used by a number of open source projects, individuals, and companies.
|
|
Using Github removes a lot of friction from taking community contributions because
|
|
it has a well understood workflow and a huge proportion of your potential contributors
|
|
already have an account there.
|
|
I don't have statistics to back up the claim that a number of companies use the
|
|
hosted on the cloud version of both tools, other than the option to buy both exist,
|
|
and there is no short of articles proclaiming the awesomeness of using B2B subscription
|
|
SaaS products.
|
|
|
|
I'm not a huge fan of putting components that are integral to our ability to do work
|
|
on (and only on) the internet in the defence and "dirty" commercial sectors.
|
|
24/7 good internet connectivity is not something we should assume exists in the sectors
|
|
we want robots to operate in, and we should build our workflows with that in my mind, picking
|
|
tools that we can bring with us.
|
|
This neccessitates a very "Edge" focused mentality towards the cloud, which biases my perception
|
|
towards picking tools I can self host.
|
|
Particularly, tools I can self host on hardware that can be brought with me when I can't assume
|
|
24/7 connectivity.
|
|
My original goal in setting up my own development stack was to see how far I could reasonably
|
|
build my own "Cloud on the Edge" that could be brought with me as part of a disconnected
|
|
command center if the need arised.
|
|
|
|
A git forge specifically is a very important part of a modern development stack.
|
|
Git forges are the primary way code is shared between developers, and without
|
|
a git forge modern software development in teams would have to radically changed.
|
|
Git forges are more and more being used as the single source of truth for things like
|
|
configuration management, with modern CD workflows basically boiling down to pull
|
|
something from a git repo and do the thing in it.
|
|
|
|
# Why I chose gitea?
|
|
|
|
I currently use gitea for as my personal git forge.
|
|
Gitea is an open source git forge that heavily borrows from Github's
|
|
UI and feature set.
|
|
Gitea is extremely light weight, with a number of people online running
|
|
it on Raspberry Pi's.
|
|
|
|
There are two reasons I chose to go with gitea.
|
|
|
|
1. It is extremely light weight and easy to host.
|
|
I was able to get a test version running on my laptop in a container running very quickly.
|
|
Once I decided to fully move to it, setting it up on Kubernetes was farily straight forward.
|
|
I've not looked at its resource useage on my currenty cluster, but I know pre-Kubernetes
|
|
I ran it on a Vm with less than 1Gb of RAM.
|
|
|
|
2. It has the best community support.
|
|
When looking at other tools that integrate with a git forge, I noticed
|
|
pretty much all of them natively have support for Github, most of them also
|
|
supported self hosted Gitlab, and if they support anything else without using
|
|
SSH directly, it's Gitea.
|
|
|
|
With that being said, I did have some concerns initially and spent a lot of energy looking
|
|
for better alternatives.
|
|
Particularly:
|
|
|
|
1. Looking at their public Github, I didn't get the feeling the project was very mature.
|
|
It's hard to put a finger on why I felt (and still feel) that, but there is something about
|
|
building something that is so unbashedly a clone that feels immature to me.
|
|
2. The maintainers are mostly in China, which makes it challenging to ever push at work.
|
|
This may come off as Xenophobic, but in the national defense field, our customers sort of are
|
|
supposed to be distrustful of other countries, and their requirements flow down.
|
|
|
|
## Other Options
|
|
|
|
### Gitlab Community Edition
|
|
|
|
One of the options I really wanted to like was Gitlab, particularly their open source
|
|
free edition.
|
|
As I mentioned earlier, outside of Github, Gitlab has the best community support, and I know
|
|
of a number of Open Source projects that aren't on Github that use it.
|
|
|
|
Unfortuntely, Gitlab is fat, requiring an insane amount of RAM to just idle.
|
|
I tried running it on my laptop in a VM with 4Gb of RAM, and with the system idling, and
|
|
the only thing happening being me in the admin panel, browsing, the server kept getting OOM'd
|
|
killed.
|
|
Their docs say the minimum amount of RAM is 4Gb and they are not kidding.
|
|
|
|
### Onedev
|
|
|
|
Onedev is an all in Git forge, largely produced by one guy.
|
|
|
|
I really wanted to like Onedev, and ran it as my primary Git forge before
|
|
my last install of Gitea.
|
|
Unfortunately, there were just too many little UI bugs that added up so I
|
|
couldn't really suggest anyone else use it at like work, and again its
|
|
mostly developed by one guy.
|
|
|
|
It ran great on a VM with very little RAM, though.
|
|
|
|
### Gerrit
|
|
|
|
[^dev-stack-definition]: I'm going to use *development stack* in this article to refer to the combination
|
|
of a place to host git repos, do code reviews, run CI/CD, and host packages, for lack of a better
|
|
term.
|
|
|
|
<!--
|
|
Why:
|
|
1. All sorts of programming tools support git and using git for versioning.
|
|
2. Expecially with gitops being a real thing.
|
|
3. But we want to maintain control and be able to still operate completely offline.
|
|
|
|
Options:
|
|
1. Gitea
|
|
2. gitlab
|
|
3. onedev
|
|
4. gerrit
|
|
|
|
gitea:
|
|
1. Lightweight
|
|
2. Easy to host, just add a docker container.
|
|
3. Not the most mature open source community based on their
|
|
github PRs.
|
|
4. They host their development on github...
|
|
5. Heavy development in China, which is not great for US Defense
|
|
oriented companies
|
|
|
|
gitlab:
|
|
1. Most feature complete, with really good integrations with all kinds of stuff.
|
|
2. Almost every thing I've seen integrates with gitlab.
|
|
3. Fat. Hosted on a VM with 4Gb of RAM, the server kept getting OOM killed when I
|
|
was just logged into the admin panel. I currently host all my infrastrture
|
|
apps in a single VM with 4Gb of ram.
|
|
|
|
Onedev:
|
|
1. Has lots of features.
|
|
2. LIghtweight
|
|
3. Only a single developer doing most of the development, no real open source community.
|
|
4. Lots of little bugs that added up.
|
|
|
|
gerrit:
|
|
1. Had the better review process
|
|
2. Really easy to write custom integrations with.
|
|
3. Felt "powerful" using it.
|
|
4. Code display interface sucks.
|
|
5. Workflow very different than github.
|
|
|
|
-->
|