diff options
Diffstat (limited to 'GitSelfhost.html')
| -rw-r--r-- | GitSelfhost.html | 106 |
1 files changed, 106 insertions, 0 deletions
diff --git a/GitSelfhost.html b/GitSelfhost.html new file mode 100644 index 0000000..f63bc6b --- /dev/null +++ b/GitSelfhost.html @@ -0,0 +1,106 @@ +<h1> Selfhosting a git GUI server </h1> +<p> +All good things must come to an end. The carefree childhood, that one ramen you used to buy but they don't make anymore. So did +github - over the time it turned from a developer-first platform with great QoL things like CI/CD through actions and web-based +merge conflict resolution to AI trashcan that dies way too often for a glorified SSH file storage (saw a screenshot recently - +they are barely holding on a single 9 in service uptime) and charges you to give them your code to train the worst agent on market +. I have had enough of this a long time ago but only recently found time to host something personal to replace it. +</p> +<p> +Well, not exactly. The old PC I plugged into internet permanently has served me my bare repositories for more than half a year +now but it wasn't particularly easy to use. The main issue was that you would have to SSH into the server to watch the repository +list. The other issue was that I couldn't watch my commit history without cloning it and typing git log. Despite that, I kept +using it alongside github until I noticed that I didn't want to use my git anymore due to pure inconvenience. That's when I +decided to stop being lazy and host something. </p> +<h2> The many routes </h2> +<p> +While doing research I encountered a couple of many modern contenders: +</p> +<ul> + <li> GitLab - a fully-featured git backend with the amount of support only comparable to its <a href="https://en.wikipedia.org/wiki/2024%E2%80%93present_global_memory_supply_shortage">RAM </a> consumption </li> + <li> Gitea - a slightly less bloated backend widely used by companies (can't find examples out of the blue but there are many. Source - trust me bro) </li> + <!-- Turns out you can't selfhost codeberg instance. Oops --> + <!-- <li> Codeberg - the one that absolute GOATs at <a href="https://ziglang.org/news/migrating-from-github-to-codeberg/"> zig dev team use </a> </li> --> +</ul> +<p> +Out of presented options Gitea is a clear winner for my insane 8gb server. So naturally I chose CGit. </p> +<h2> CGit </h2> +<p> +Gitea is great when you want to own a fully featured system many users can use. Thing is, no one cares about my personal git, so +why would I waste computational power on something not a living soul would use? <a href="https://git.zx2c4.com/cgit/"> CGit </a> +was an obvious winner - lightweight, minimalistic and customizable alternative. The only issue is that documentation for it is a +disaster. </p> <p> My server runs arch linux (btw). Naturally, the first thing I do after checking out their repo is googling +'cgit arch' and get <a href="https://wiki.archlinux.org/title/Cgit"> this page. </a>. The order of execution is quite convoluted +in the article. First it tells you to download cgit, then choose a web server, then download a wrapper, then configure CGit +itself. I always use Nginx the first opportunity I get so I jump to its configuration. The second fun part is that it doesn't +work out of the box. The instructions are wrong - you have to search for the files to feed it to cgi-bin (yes, it's that breed +of software) and add them manually. Also they forgot the path to the static files so you have to find add it yourself. All in +all, I got this config: +</p> +<div class="code"> +worker_processes 1; + +# Load all installed modules +include modules.d/*.conf; + +events { + worker_connections 1024; +} + +http { + include mime.types; + default_type application/octet-stream; + sendfile on; + keepalive_timeout 65; + + server { + listen [internal port]; + + root /usr/share/cgit; + try_files $uri @cgit; + + # This has to ba added and altered to use static files + location ~* ^/(cgit.(css|png|js|svg)|favicon.ico|robots.txt|cgit_bak.css|(switch|search).svg) { + root /usr/share/webapps/cgit; + expires 30d; + } + + location ~ /.+/(info/refs|git-upload-pack) { + include fastcgi_params; + fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git-http-backend; + fastcgi_param PATH_INFO $uri; + fastcgi_param GIT_HTTP_EXPORT_ALL 1; + fastcgi_param GIT_PROJECT_ROOT /srv/git; + fastcgi_param HOME /srv/git; + fastcgi_pass unix:/run/fcgiwrap.sock; + } + + location @cgit { + include fastcgi_params; + fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi; + fastcgi_param PATH_INFO $uri; + fastcgi_param QUERY_STRING $args; + fastcgi_param HTTP_HOST $server_name; + fastcgi_pass unix:/run/fcgiwrap.sock; + } + } +} +</div> +<p> After that it required a config file that was relatively easy to write (somehow `man cgit` is good despite the rest having +close to no documentation) and after an hour of tinkering it finally came alive. The next logical thing was to customize it. <br> +The customization is fairly straightforward - you just create a single CSS file and replace the default one with it. By default +cgit looks for the static files in /usr/share/webapps/cgit (good luck finding that) and if you put files there it will gladly +eat it up. The default CSS provided by CGIT is also there. I spent an evening trying to make it look like my website and while +I'm not too happy about the result it will do. The configuration for the server you can find +<a href="https://git.physick.ru/cgit_config/"> here </a> +</p> +<h2> Afterthoughts </h2> <p> +At the time of the writing 10 days have passed. By this time according to my meter I've successfully surpassed microsoft's +uptime (around 97% vs 91% at GitHub). I understand that it might not be a valid comparison due to the lack of features and users +at my server but the fact that I'm in charge of what happens and when my server is online comforts me. I can also access it +locally if I would ever need to. So far nothing has bothered me, every time I push it gladly accepts my code and I don't have to +wait for like 20 minutes to push changes (actual situation I found myself recently into). So yeah, if you have a spare server you +should absolutely look into doing the same. I am not that delusional and I understand that not everyone can easily pull this off +so I won't propagate selfhosting here but if you were doubting about it selfhosting your infrastructure as an independent person +is 100% worth it. +</p> |