105 lines
4.0 KiB
Plaintext
105 lines
4.0 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?
|
|
|
|
## Other Options
|
|
|
|
### Gitlab
|
|
|
|
### Onedev
|
|
|
|
### 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.
|
|
|
|
-->
|