From 617bb674ffac4bf578e4acc5290481b8e06aa013 Mon Sep 17 00:00:00 2001 From: James Pace Date: Fri, 9 Feb 2024 04:24:21 +0000 Subject: [PATCH] Flesh out git article. --- _drafts/self_hosted_git_summary.qmd | 59 ++++++++++++++++++++++++++++- 1 file changed, 57 insertions(+), 2 deletions(-) diff --git a/_drafts/self_hosted_git_summary.qmd b/_drafts/self_hosted_git_summary.qmd index 97e7529..da863d3 100644 --- a/_drafts/self_hosted_git_summary.qmd +++ b/_drafts/self_hosted_git_summary.qmd @@ -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. +