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

Flesh out git article.

This commit is contained in:
James Pace 2024-02-09 04:24:21 +00:00
parent eb2e1b6852
commit 617bb674ff
1 changed files with 57 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
_drafts/self_hosted_git_summary.qmd
View File

@ -2,9 +2,64 @@
title: "Summary of Free Self Hosted Git Options"
author: "James Pace"
date: "2024/01/12"
draft: true
---
# 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.
@ -40,7 +95,7 @@ Onedev:
4. Lots of little bugs that added up.
gerrit:
1. Had the bet review process
1. Had the better review process
2. Really easy to write custom integrations with.
3. Felt "powerful" using it.
4. Code display interface sucks.