169 lines
7.9 KiB
Plaintext
169 lines
7.9 KiB
Plaintext
---
|
|
title: "Summary of Free Self Hosted Git Options"
|
|
author: "James Pace"
|
|
date: "2024/02/10"
|
|
---
|
|
|
|
# Introduction
|
|
|
|
A few years ago I started setting up my own self hosted
|
|
development stack [^dev-stack-definition] 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 shortage 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 defense 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 into the zones we operate in.
|
|
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 look radically different.
|
|
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.
|
|
Someone who has used GitHub should reasonable be able to "guess" how to
|
|
do the primary tasks they need to do on Gitea drawing on that experience.
|
|
Gitea is extremely light weight, with a number of people online running
|
|
it on Raspberry Pi's.
|
|
|
|
A number of different organizations use Gitea in some capacity:
|
|
|
|
1. OpenStack uses it as a tool to browse code.
|
|
(They do code reviews with Gerrit.)
|
|
2. Blender hosts their main git forge on Gitea.
|
|
3. Defense Unicorns puts a Gitea instance in their disconnected K8s clusters
|
|
that are provisioned with Zarf.
|
|
|
|
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 fairly straight forward.
|
|
I've not looked at its resource usage 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 is 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 our customers are and sort of are
|
|
supposed to be distrustful of other countries, and those 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.
|
|
|
|
Particularly:
|
|
|
|
1. Debian Salsa is a "hosted by the Debian project" Gitlab instance.
|
|
2. Red Hat uses the Cloud version for some of their projects, most interestingly
|
|
to me Centos Automotive.
|
|
|
|
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
|
|
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
|
|
|
|
Of the git forges I looked at, Gerrit was the only one with a unique workflow that
|
|
wasn't the Github Pull Request style.
|
|
The distinguishing component of Gerrit's workflow is that a PR will only consist
|
|
of a single commit at any one point in time, and feedback is implemented by ammending
|
|
and then replacing that one commit until the PR has been accepted.
|
|
The workflow basically boils down to:
|
|
|
|
1. Make a change you want to PR on a branch with all the changes in a single commit.
|
|
2. Push the commit to a special URL. It will become a PR.
|
|
3. Get feedback.
|
|
4. Implement the feedback and ammend it to the one commit for the PR.
|
|
5. Force push the new commit, get more feedback, and repeat until the commit
|
|
gets merged.
|
|
|
|
Gerrit has some custom tooling built on top of Git which makes this easy to do.
|
|
|
|
I actually liked the workflow and think that in a fast moving software shop it would have
|
|
a lot of benefits.
|
|
It's pretty similar to merging PRs with squash merges in Gitub style workflows, except for
|
|
the squash merge is done though the whole development process not just at merge.
|
|
I think having a commit per PR, even for things in progress, would make managing integration
|
|
branches that contain multiple in progress PRs easier to manage.
|
|
|
|
I also like Gerrit's API, and it was very easy to write custom integrations with it,
|
|
|
|
The main problem I had was with Gerrit's UI for code browsing, which is basically nonexistent,
|
|
and makes Gerrit completely unusable as a code portfolio, which is one of the things my public
|
|
repos effectively are.
|
|
|
|
The other issue is that as much as I think the workflow would be nice in a fast moving software shop,
|
|
my personal projects where I don't even really do reviews just isn't that.
|
|
|
|
# Conclusion
|
|
|
|
When looking to host a git forge I looked at four different options before ultimately going with Gitea,
|
|
due to it's ease of host and good community support.
|
|
|
|
The other options I looked at each have interesting properties, but weren't suitable for what I'm doing
|
|
right now.
|
|
|
|
[^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. |