public
/
til.jpace121
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Publish git post.

This commit is contained in:
James Pace 2024-02-11 01:02:09 +00:00
parent 134f52b118
commit 8dce7c8714
1 changed files with 77 additions and 64 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

141
_drafts/self_hosted_git_summary.qmd → posts/self_hosted_git_summary.qmd
View File

@ -1,13 +1,13 @@
---
title: "Summary of Free Self Hosted Git Options"
author: "James Pace"
date: "2024/01/12"
date: "2024/02/10"
---
# Introduction
A few years ago I set started setting my own self hosted
development stack [^dev-stack-defintion] at home in Kubernetes.
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,
@ -23,25 +23,25 @@ it has a well understood workflow and a huge proportion of your potential contri
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
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 defence and "dirty" commercial sectors.
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.
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.
(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.
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.
@ -51,22 +51,32 @@ something from a git repo and do the thing in it.
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 farily straight forward.
I've not looked at its resource useage on my currenty cluster, but I know pre-Kubernetes
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's Gitea.
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.
@ -76,27 +86,33 @@ Particularly:
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.
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
# Other Options
### Gitlab Community Edition
## 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 Clodu 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'd
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
Onedev is an all in Git forge, largely produced by one guy.
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.
@ -106,51 +122,48 @@ mostly developed by one guy.
It ran great on a VM with very little RAM, though.
### Gerrit
## 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.
<!--
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.
-->
term.