WPF-OpenSource/src/studienarbeit/4_sourcehut.md

Sourcehut

Eine Git-Hosting-Plattform ohne Pull-Requests, einer spartanischen Weboberfläche und einem mächtigen Buildsystem - so lässt sich Sourcehut am besten zusammenfassen.

SourceHut begann im Oktober 2016 als Hobbyprojekt von Drew DeVault. Drew wollte eine alternative zu den etablierten Git-Hosting-Diensten entwickeln, die den klassischen E-Mail-basierten Git-Workflow unterstützt anstatt das Funktionsprinzip von GitHub zu kopieren.

2018 war die Alpha-Version der Software öffentlich unter https://sr.ht verfügbar.

Die Plattform besteht aus einzelnen Komponenten für die verschiedenen Features:

• meta.sr.ht (Login und Benutzerverwaltung)
• hub.sr.ht (Projektverwaltung)
• git.sr.ht / hg.sr.ht (Git/Mercurial Hosting)
• todo.sr.ht (Issues)
• lists.sr.ht (Mailinglisten)
• man.sr.ht (Wiki)
• paste.sr.ht (Pastebin)
• builds.sr.ht (Continuous Integration)
• pages.sr.ht (Statisches Webhosting)

Jede dieser Komponentent besteht wiederum aus 2-3 Diensten: dem in Python/Flask implementierten Webfrontend, einem in Go geschriebenen API-Server und eventuell noch zusätzliche Dienste wie eine Task Queue.

Jede Komponente legt ihre Daten in einer eigenen PostgreSQL-Datenbank ab. Zusätzlich wird noch eine gemeinsame Redis-Instanz als Cache und Event Queue verwendet.

Hier ist eine Übersicht über die einzelnen Dienste:

Installation

Da Sourcehut aus mehreren Services für die einzelnen Features besteht, ist die Einrichtung mit deutlich mehr Aufwand verbunden. Die Anleitung zur Installation findet sich auf der Dokumentationsseite des Projekts. Allerdings ist diese Anleitung nicht vollständig und ich musste an einigen Stellen im Quellcode der Software nachschlagen, wie bestimmte Features zu konfigurieren sind.

Erschwerend kommt hinzu, dass Sourcehut an vielen Stellen keine aussagekräftigen Fehlermeldungen liefert. Beispielsweise hatte ich das Problem, dass builds.sr.ht keine VMs starten konnte, da diese standardmäßig mit 4GB RAM konfiguriert sind - zu viel für meine Test-VM. Der einzige Fehler, der in diesem Fall auf der Webseite angezeigt wird, ist der, dass das Build-System innerhalb einer bestimmten Zeit keine Verbindung zur VM aufbauen konnte. Der OOM-Fehler beim Start wurde weder geloggt noch an den Nutzer weitergegeben.

Auf der Dokumentationsseite wird erwähnt, dass sich das Projekt noch im Alpha-Stadium befindet, es ist also zu hoffen, dass die Dokumentation in Zukunft verbessert wird.

Ich habe sämtliche Schritte, die zur Installation meiner Testinstanz erforderlich waren, im Anhang aufgelistet.

Systemanforderungen

Sourcehut ist auf jedem System lauffähig, das Python 3.10 und Go unterstützt. Allerdings sind die Pakete momentan nur für die amd64-Architektur verfügbar. Wer Sourcehut also auf einem Raspberry Pi oder ARM-Server installieren will, muss die Pakete selbst kompilieren.

Die CPU-Auslastung im Leerlauf ist gering (ca. 1%). Bei aufwändigen Git-Operationen sieht die Sache jedoch anders aus. Wenn man sich z.B. die Änderungshistorie der Makefile des Linux-Kernels anzeigen lässt, läuft git.sr.ht 30 Sekunden lang mit 100% CPU-Auslastung, bis Nginx die Anfrage wegen Zeitüberschreitung abbricht. Dieses Problem lässt sich auch auf der offiziellen Instanz reproduzieren (Link zum Testen).

Zum Vergleich: Die Ausführung des Befehls git --no-pager log Makefile | head -n 1000 benötigte auf meinem Testsystem nur 100ms.

Beim Arbeitsspeicherverbrauch macht sich die Microservice-Architektur negativ bemerkbar: jeder Python-Dienst reserviert 90-100MB, die in Go geschriebenen API-Server kommen mit 20-30MB RAM aus. Da die gesamte Sourcehut-Installation aus 14 Python- und 8 Go-Services besteht, summiert sich der Arbeitsspeicherbedarf auf ca. 1,5GB.

Bedienung

Sourcehut's Weboberfläche ist spartanisch designt und kommt fast ohne JavaScript aus. Dadurch ist die Webseite ohne Probleme in alten Geräten und Browsern benutzbar.

Die Repository-Ansicht ist klar an GitWeb angelehnt und zeigt die Dateien ähnlich wie der ls -l-Befehl zusammen mit Größe und Berechtigungen an.

Genau wie GitWeb (und ls) platziert Sourcehut Ordner nicht vor Dateien, was das Auffinden bestimmter Ordner unter vielen Dateien erschwert.

Eine Suchfunktion gibt es nicht, dadurch ist es schwierig, auf der Webseite durch große Projekte zu navigieren.

Hinzu kommt, dass die Webseite nur Code und Markdown-Dokumente darstellen kann. Bilder, PDF-Dokumente oder andere Markupsprachen wie RST werden nicht unterstützt.

Die einzelnen Komponenten von Sourcehut sind eigenständige Webanwendungen. Dies hat den Vorteil, dass man nur einen Teil von Sourcehut installieren kann, wenn man beispielsweise den Build-Service oder die Mailinglisten nicht benötigt. Allerdings macht diese Aufteilung die Bedienung an vielen Stellen hakelig. Es gibt zwar eine zentrale Projektverwaltung (hub.sr.ht), die Repositories, Issue-Tracker und Mailinglisten zu bestimmten Projekten zuordnet. Allerdings ist diese Verlinkung eine Einbahnstraße: von der Projekseite auf dem Hub kann man alle zugehörigen Repositories, Issue-Tracker und Mailinglisten aufrufen, befindet man sich aber bspw. in einem Repository, kann man das zugehörige Projekt nicht ohne weiteres ermitteln.

Projektansicht im SourceHut Hub

Sourcehut unterscheidet sich von GitHub und anderen Code-Hosting-Plattformen vor allem dadurch, dass es zur Kollaboration zwischen Entwicklern keine Pull-Requests verwendet. Stattdessen basiert das System auf den "klassischen" Git-Workflow, also dem Austausch von Patches via E-Mail. Projekteigentümer können Mailinglisten einrichten und darüber Patches empfangen.

Dies hat den Vorteil, dass außenstehende Entwickler sich nicht auf der Plattform registrieren müssen und ausschließlich via E-Mail mit den Maintainern des Projekts kommunizieren können.

Sourcehut bietet Entwicklern auch die Möglichkeit, über die Weboberfläche Patches zu erstellen und zu versenden. Dazu muss man das Repository zuerst auf der Plattform klonen, die eigenen Commits hochladen und diese anschießend in der Weboberfläche auswählen.

Auch wenn dieser Workflow sicherlich Vorteile mit sich bringt, muss man feststellen, dass dies für die meisten Entwickler ungewohnt und umständlich ist. Entwickler, die bisher nur mit GitHub und ähnlichen Plattformen gearbeitet haben, werden beim Versuch, zu einem Projekt beizutragen, eventuell auf Hindernisse stoßen.

Es gibt auch ein CLI-Tool namens hut, um die verschiedenen Sourcehut-Dienste mit der Kommandozeile zu bedienen. Das Tool erlaubt das Erstellen von Issues, Hochladen von Releases, Starten von Builds, Veröffentlichen von Webseiten, Hinzufügen von SSH-Keys und einiges mehr.

Import bestehender Projekte

Die Sourcehut-Weboberfläche erlaubt auf lediglich den Import von öffentlichen Git-Repositories per clone. Es gibt keine Möglichkeit zum Import von Issues und Pull-Requests werden wie oben erwähnt nicht unterstützt.

Zusatzfeatures

Wie bereits beschrieben besteht Sourcehut aus einer Vielzahl von Diensten, den Entwicklern neben Git-Hosting und Issue Tracking diverse Zusatzfeatures bieten.

man.sr.ht ist ein auf Git basierendes Wiki, das in Markdown geschriebene Dokumentationstexte darstellen kann. Allerdings bietet es kaum Features: der einzige Unterschied zum Betrachten von Markdown-Dateien in git.sr.ht ist das Seiteninhaltsverzeichnis, das man.sr.ht oben anfügt. Es gibt kein Inhaltsverzeichnis über die gesamte Dokumentation, genauso wenig wie eine Suchfunktion.

paste.sr.ht ist ein Pastebin zum Speichern und Veröffentlichen von kleineren Texten, Skripten und Codeausschnitten. Man kann Pastes öffentlich oder privat speichern und es gibt auch die Möglichkeit, Textdateien mit dem hut-CLI-Tool hochzuladen.

pages.sr.ht ist ein Webhosting-Dienst, der es einem erlaubt, statische Webseiten unter einer persönlichen Subdomain zu veröffentlichen. Hierfür muss man sämtliche Dateien als tar.gz-Archiv komprimieren und anschließend mit dem hut-Tool hochladen.

Das Issue-System von Sourcehut (todo.sr.ht) ist jedoch sehr rudimentär. Es gibt außer Labels und der Möglichkeit, verantwortliche Personen zuzuweisen keine Zusatzfunktionen, die das Projektmanagement erleichtern. Für größere Projekte ist daher die Verwendung einer zusätzlichen Projektmanagement-Software wie Redmine nötig.

Continous Integration

builds.sr.ht ist ein sehr leistungsfähiges und einfach zu verwendender CI-System.

Builds können über die Weboberfläche, eine API oder durch Git-Pushes und auf der Mailigliste eingegangene Patches initiiert werden. Zum Ausführen der Builds werden virtuelle Maschinen (mit QEMU/KVM) gestartet, wodurch die Build-Umgebung vom Server isoliert ist.

QEMU erlaubt es auch, andere CPU-Architekturen zu emulieren und so beispielsweise Embedded Linux-Anwendungen zu testen.

Sourcehut Builds werden durch yaml-Manifests beschrieben. Die Syntax ist sehr simpel gehalten. Manifests bestehen aus dem Namen des VM-Images, den benötigten Paketen und Repositories und einem oder mehreren Shell-Skripten.

image: alpine/latest
packages:
  - cargo
sources:
  - https://code.thetadev.de/ThetaDev/short-uuid.git
tasks:
  - test: |
      cd short-uuid
      cargo test

Es gibt auch die Möglichkeit, für den Build benötige Secrets wie API-Keys und SSH-Schlüssel zu hinterlegen. Die Secrets werden auf der Build-VM in Dateien abgelegt, von wo aus sie in Buildskripten verwendet werden können (z.B. cargo publish --token "$(<~/.cargo-token)"). Zudem gibt es die Möglichkeit, SSH- und GPG-Schlüssel automatisch zu importieren.

Ein besonderes Feature von builds.sr.ht ist die Möglichkeit, fehlgeschlagene Builds zu analysieren. Schlägt ein Build fehl, läuft die entsprechende VM noch 10 Minuten weiter. In dieser Zeit kann man sich per SSH mit dem Build-Server verbinden und kann Befehle in der entsprechenden Build-VM ausführen. Auf diese Weise kann man Logdateien inspizieren oder den Build mit Konfigurationsänderungen neu starten, ohne jedes Mal das Buildmanifest zu ändern und neu zu übermitteln.

Allerdings bietet Sourcehut Builds nicht die Möglichkeit, zu spezifizieren, wann ein Build ausgeführt werden soll. Builds werden immer dann gestartet, wenn ein Branch in einem Repository aktualisiert wird, in dem sich eine .builds.yml-Datei befindet. Eingehende Patches in der Mailingliste können ebenfalls einen Build startet.

Es gibt jedoch keine Möglichkeit, Builds nur dann zu starten, wenn ein bestimmter Branch oder bestimmte Dateien aktualisiert wurden. Dies kann beispielsweise in Monorepos (Repositories mit mehreren Projekten) zu unnötig lange dauernden Builds führen.

Öffentliche Instanzen

Die öffentliche Sourcehut-Instanz, die von Drew DeVault und seiner Firma betrieben wird, befindet sich unter https://sr.ht.

sr.ht ist der einige mir bekannte Git-Hosting-Anbieter, der ein kostenpflichtiges Abonnement für das Erstellen eigener Projekte erfordert. Solange sich Sourcehut im Alpha-Stadium befindet, ist das Abo allerdings optional (außer für die Nutzung des Build-Service). Das Abonnement kostet 20€ im Jahr, man kann auch auf freiwilliger Basis bis zum 100€ bezahlen, um das Projekt zu unterstützen.

Die kostenpflichtigen Mitgliedschaften erlauben Sourcehut, finanziell unabhängig zu sein und nicht den Entscheidungen von Investoren unterworfen zu sein. Sourcehut veröffentlicht seine jährlichen Einnahmen und Ausgaben auf ihrem Blog und gibt an, seit 2019 Profit zu erwirtschaften.

Bekannte Projekte, die auf sr.ht gehostet werden sind das alternative Instagram-Frontend Bibliogram, microblog.pub, eine persönliche Microblogging-Anwendung mit ActivityPub-Unterstützung und natürlich Sourcehut selbst. Insgesamt hostet sr.ht ca. 7100 Projekte.

Es gibt auch Open-Source-Projekte, die ihren Code auf anderen Plattformen hosten und nur das Build-System von Sourcehut nutzen. Beispielsweise benutzt die Linux-Distribution postmarketOS Sourcehut Builds zum Bau ihrer Pakete.

Wichtig ist noch zu erwähnen, dass die offizielle Sourcehut-Instanz keine Projekte erlaubt, die mit Blockchain oder Kryptowährungen zu tun haben. Sourcehut begründet dies damit, dass Kryptowährungen häufig für Betrug und andere Verbrechen eingesetzt werden und große Mengen an Ressourcen verschwenden.

Abgesehen von der offiziellen Instanz gibt es sehr wenige weiterem öffentlichen Sourcehut-Instanzen, was wohl auch dem komplizierten Einrichtungsprozess geschuldet ist.

Es existiert eine Instanz unter gnu.org, die sich allerdings im Entwicklermodus befindet und über keine öffentlichen Projekte verfügt. Die größte alternative Sourcehut-Instanz, die ich gefunden habe, ist https://code.netlandish.com/. Die Instanz wird von einer Webentwicklungsfirma betrieben, beherbergt 9 öffentliche Projekte und erlaubt keine Registrierung von Außenstehenden.

Fazit

Das Highlight von sr.ht ist meiner Meinung nach der CI-Dienst. Während die meisten anderen CI-Dienste an Repositories gekoppelt sind, erlaubt es Sourcehut, einfach ein Build-Manifest mit dem CLI-Tool oder dem Formular auf der Website abzuschicken und ausführen zu lassen. Die Möglichkeit fehlgeschlagene Builds zu analysieren ist ebenfalls einzigartig.

Allerdings ist die Einrichtung von Sourcehut sehr aufwändig und einige grundlegende Features wie eine Suchfunktion fehlen weswegen ich das System in seinem momentanen Zustand nicht empfehlen kann.

Hinzu kommt, dass Sourcehut trotz seiner spartanischen Weboberfläche und seinem reduziertem Funktionsumfang das System mit dem zweithöchsten Ressourcenverbrauch im Test war.

Da sich Sourcehut wie gesagt noch im Alpha-Stadium befindet, lohnt es sich jedoch das Projekt weiter zu verfolgen.

Quellen

• Projektseite https://sr.ht/~sircmpwn/sourcehut/
• Sourcehut Blog https://sourcehut.org/blog/