Gitea oder Forgejo?

Das ist hier die Frage.

Oder: Grrrr!

[Achtung: Informatik-Thema, langweilig, staubtrocken, für viele unlesbar]

Also, die Sache ist ja die: Informatiker verwalten ihren Krempel ja schrecklich gerne in sogenannten Source-Code-Repositories. Quelltexte jeder Art, meist von Programmen, werden in versionierter Form in einem Speicher abgelegt, der Änderungen nach Datum nachvollziehbar macht und alte Versionen reproduzieren kann. Wer hat im Februar 2019 etwas am Quelltext geändert? Und was? Oder: Verdammt, die Software läuft nicht, neulich lief sie doch noch. Ich brauche sofort die Version von vorletzter Woche! Oder: Warum hat dieser Programmteil vor 2 Jahren noch funktioniert und heute nicht mehr? Wann hat das das letzte Mal funktioniert?

Und weil Informatiker gern alles mögliche als Quelltext ablegen und dann in einem automatisierten Verfahren die Artefakte daraus erzeugen, machen sie das mit möglichst allem, weshalb Informatiker auch Texte, Bücher usw. lieber mit LaTeX schreiben und in einem Repository halte, als etwa mit Word. Oder auch 3D-Objekte, Musikkompositionen, Notizen, Kochrezepte, all den Kram legen wir leidenschaftlich gerne in solchen Repositories ab, weil sie uns auch ermöglichen, von mehreren Rechnern oder mit mehreren Personen daran zu arbeiten, ohne dass sich das ins Gehege kommt.

Ich selbst benutze die ja auch exzessiv. Angefangen an der Uni, damals mit RCS (obwohl von Tichy, aber zu dem Zeitpunkt hatte ich den Streit mit dem noch nicht), was aber noch kaum brauchbar war, dann CVS, später SVN (Subversion), und dann GIT. Glücklicherweise gab es immer auch Konversionsprogramme, weshalb ich GIT-Repositories mit alten Einträgen aus Zeiten habe, zu denen es GIT oder SVN noch gar nicht gab. Eben mit anderen Repositories angelegt und dann konvertiert. Ja, ich weiß, es gibt auch andere, wie Mercurial, damit habe ich aber nie etwas gemacht, und GIT ist einfach der de facto Standard geworden und ziemlich gut. Etwas kompliziert vielleicht – normalerweise kennt man so seine oft verwendeten Grundbefehle, und Sonderfälle, Tricks und Kunststücke muss man jeweils nachschauen.

Wo?

Eine zentrale Frage ist immer: Wo legt man seine Repositories ab, wo speichert man sie?

Dafür haben sich einige öffentliche Seiten und Dienstleister etabliert, allen voran und am bekanntesten github.com. Für öffentliche Projekte (Open Source) kostenlos, für nichtöffentliche Projekte gegen Geld. Wurde vor ein paar Jahren vom Erzfeind des Open-Source-Wesens, von Microsoft, übernommen. Schlimme Sache, auch weil github.com damals irgendwie nach links/woke/code of conduct rutschte. Die dubiosen Geschichten habe ich aber nicht mehr so genau in Erinnerung, die müsste ich erst nachsehen.

Ob man seine Repositories beim Dienstleister ablegt, ist immer so eine Frage. Einerseits zentral, Cloud und so, man muss ich um nichts kümmern, und es gibt diese „Actions“, zu denen ich noch komme. Andererseits natürlich ein Sicherheitsproblem, und es kostet Geld. Sagen wir es so: Wenn man Open-Source-Projekte macht, die man öffentlich zugänglich machen will, bei denen man öffentlich kooperieren will, Bug Reports haben will, pull requests reinziehen will und so weiter, ist das schon prima. Und wenn man häufig „Actions“ ausführen will, also weitere Arbeitsschritte ausführen lassen will, um nicht nur den Quelltext anzubieten, sondern auch das Testen der Software, das Compilieren, das Zusammenpacken von Software zu Paketen, erstellen von Dokumentation, Docker-Images und solchen Kram automatisch erstellen will und bereit ist, dafür zu zahlen, kann das auch interessant sein.

In allen anderen Fällen, besonders bei privaten Repositories und vertraulichen Dingen wie Buch- und Gutachtentexten usw., würde ich immer empfehlen, die Repositories lokal, auf eigenen Rechnern im eigenen Netzwerk zu hosten.

Wie lokal hosten?

Was braucht man, um GIT-Repositories lokal zu hosten?

Die Antwort: Nichts. Man braucht gar nichts, außer ein bisschen Plattenplatz, denn GIT kann das alles schon selbst. Man legt in irgendeinem Verzeichnis per git init --bare NAME ein leeres Verzeichnis an und kann das dann per ssh mit Pfadangabe als Repository von anderen Rechnern aus verwenden. (Man bekommt eine politisch korrekte Nachrichten, dass der Haupt-Branch wie bisher noch „master“ lautet – was ja inzwischen zu den bösen Wörtern gehört – sich das in Zukunft ändern wird und man doch bitte Alternativen wie ‘main’, ‘trunk’ und ‘development’ in Betracht ziehen möge.

Und das reicht eigentlich völlig – wenn es einem nur um das Speichern geht. Man kann zwar „hooks“ einbauen, also Skripte, die beispielsweise beim einchecken von Änderungen aufgerufen werden, aber die eigenen sich nur für kleine Aufgaben, weil der Vorgang des Eincheckens dauert, bis das vorbei ist. Man kann beispielsweise eine Mail verschicken, aber zum Testen und Compilieren eignet sich das nicht.

Oder, wie man das in Fachkreisen nennt: CI/CD (Continuous Integration, Continuous Delivery/Deployment). ein Begriff aus dem Bereich der „DevOps“. Die Idee dahinter ist, möglichst alles zu automatisieren, um auf Änderungen schnell und automatisiert reagieren zu können, im Gegensatz etwa zum extrem bürokratischen „Wasserfall-Modell“. Der Gedanke ist der, dass am Quelltext irgendetwas ändert und ihn ins GIT eincheckt, und alles weitere, Compilierung, Testen, Paketierung, „Deployment“, also die Softwareverteilung auf die Test- und Produktivsysteme vollautomatisch und möglichst schnell passiert, also nicht nur, wie bei GIT selbst, der Quelltext verwaltet wird, sondern alle weiteren Schritte, die aus dem Quelltext folgen, durchautomatisiert werden.

Bisher habe ich alles, was bei mir zu tun ist, im ausgecheckten Bereich, also auf dem Arbeitsplatz mit Makefiles, Rakefiles, docker-compose und solchen Dingen ausgeführt, das wird mir aber zu umständlich. Hier noch schnell das Docker-Image neu bauen, ach, da noch die Software ziehen und compilieren, ach, dort noch ein Package bauen. Ich habe das zwar alles schön automatisiert, aber Aufrufen tue ich das bisher immer manuell auf dem Arbeitsplatz.

Wird mir zuviel und umständlich, kostet zuviel Zeit, vor allem unterwegs.

Für das Problem gibt es eine Lösung: Die „Actions“ auf github.com. In einem Unterverzeichnis kann man Skripte in einem bestimmten Format anlegen, die beim Eintreten definierter Bedingungen – Einchecken von Änderungen, neue Versionslabels, oder auch Zeitbedingungen wie bei cron für regelmäßige Jobs – ausgeführt werden und eben Dinge erledigen, wie Tests durchzuführen oder das Programm zu compilieren und zu Paketen zusammenzupacken, docker-images zu erstellen und so ein Kram.

Die sind sehr berüchtigt, weil die Syntax nicht so toll ist und man für viele Dinge irgendwelche Schritte ausführen muss. Neulich erst gab es einen beachtlichen Text eines Entwicklers namens Ian Duncan: GitHub Actions Is Slowly Killing Your Engineering Team , den ich über die deutsche Übersetzung auf Golem.de gefunden hatte.

Aber man sollte zumindest grundlegend in der Lage sein, die zu lesen und zu verstehen, weil einem das immer mal unterkommen kann, dass man darin einen Fehlersuchen oder in einem Quelltext schlicht und einfach nachlesen muss, wie man den compiliert. Egal, wie gruselig diese Actions sind, sie haben den Vorteil, dass man damit zumindest im Prinzip dokumentiert hat, was mit dem Quelltext zu tun ist.

Gibt es Alternativen?

Ja.

Ein Klassiker ist Jenkins. Lange ein führendes Tool, um den ganzen CI/CD-Kram lokal selbst zu machen. Ich hatte mal beruflich am Rande damit zu tun. Mich stören verschiedene Dinge daran. Beispielsweise, dass man, um das Ding überhaupt verwenden zu können, jede Menge Plugins installieren muss und wieder nicht weiß, was die eigentlich machen. Hinterher hat man zwar ein Plugin, das einem ein Programm compiliert und zusammenpackt, aber man weiß nicht so genau, was das macht, und ohne das Plugin kann man das nicht einfach so nachvollziehen. Mir ist dabei viel zu viel „gemausklickt“ – ich mag das nicht, wenn man Software und deren Einstellungen per Mausklick reproduzieren muss und die Installation nicht mit Tools wie puppet, ansible, docker-compose automatisieren kann, um sie identisch reproduzieren zu können. Das ist alles recht zusammengekleistert und Unordnung mit schöner Mausklickoberfläche, aber bei vielen Plugins Meldungen wie

Warning: This plugin version may not be safe to use. Please review the following security notices:

Credentials stored in plain text

Und zu vielen Plugins wird angegeben, dass das letzte Release so 9 oder auch 12 Jahre alt ist.

Letztlich ist das nur ein graphisches Frontend dafür, eine unstrukturierte wilde Sammlung aus Plugins aufzurufen. Letztlich wird der ganze Kram, soweit mir bekannt, in einer Datenbank gespeichert und muss, wenn man das woanders laufen lassen will, händisch per Maus übertragen werden.

Mir gefällt das nicht. Die anderen Ansätze wie bei Github, die Arbeitsschritte in einem Unterverzeichnis im Git-Repository selbst abzulegen, ist zwar viel formaler und syntaktisch anstrengender, aber dann hat man seinen Kram beisammen.

Dann gibt es Gitlab, als Konkurrent zu github entstanden, und das gefällt mir eigentlich auch deutlich besser. Sie bieten es als kommerzielle Dienstleistung an, man kann es aber auch eine („Community Edition“) abgespeckte Version selbst hosten und dabei kostenlos verwenden. Eigentlich gefällt (gefiel) mir Gitlab deutlich besser, weil die Konfigurationssprache für die Aktionen deutlich einfacher und direkter ist, man nicht ständig irgendwelche fremden Plugins und Libs verwenden muss. Es ist aber inzwischen viel zu aufgebläht und träge, vollgepumpt, weil man daraus ein kommerzielles Produkt gemacht hat und die freie Version nur noch irgendwie mitschleppt.

Eigentlich würde mir Gitea sehr gefallen. Klein, kompakt, auf das Wesentliche reduziert, hat aber jede Menge eigene Paketrepositories (Debian-Pakete, Gems, Docker images usw.) schon eingebaut, und ist sehr ressourcensparend (die Arbeit macht, wie bei den meisten, ein externer „Runner“ auf anderen Maschinen), verwendet aber leider auch die gruseligen Actions von github, weil es quasi ein Github zum Selbsthosten sein will. Damit könnte man zur Not leben. Eigentlich wäre das das Tool der Wahl.

Aber, ach.

Ich hatte das vor zwei, drei Wochen mal zum Test installiert und war eigentlich sehr zufrieden damit, zwei Tage später ging es aber nicht mehr. Warum? Ich hatte es unter Ubuntu per snap installiert, und es hatte einen Update gegeben, snap hatte automatisch die neue Snap-Version installiert, und bei der hatten sie zum Zusammenbinden einen Fehler gemacht: Ich hatte bei der Konfiguration beim ersten Lauf den Standard-Wert stehen gelassen, dass die Datenbank sqlite verwendet, weil ich bei der Handvoll an Repos, für die ich das einsetzen würde, keine große Datenbank brauchte. Der snap-Update hatte aber keinen sqlite-Support mehr, und konnte deshalb nicht mehr starten. Das ist übel, wenn man das produktiv einsetzt, es dringend braucht (CI/CD) und dann geht’s nicht. Gut, Fehler können passieren, ich hatte das gemeldet, andere auch, und es stellte sich heraus, dass sie einen Fehler im Build-Prozess hatten, und das Skript, was das für die snap-Version kompiliert, nicht auf die Konfigurationsdatei zugreifen konnte. Kann passieren, Problem erkannt. Dann dauerte es aber, und noch immer werden auf latest/stable, latest/beta und latest/candidate die Versionen verteilt, die nicht funktionieren. Auf latest/edge gibt es eine development-Version, die zwar funktioniert, aber die man nicht produktiv einsetzen möchte.

Ich habe gefragt, warum man die Pakete nicht neu erstellt, nachdem man den Fehler erkannt und behoben hat. Antwort: Die werden dann automatisch neu erzeugt, sobald eine neue Version erscheint.

Die lassen den Nutzer also einfach so über mehrere Wochen hängen, obwohl sie wissen, dass das Paket nicht funktioniert.

So etwas ist produktiv unbrauchbar. Es gibt Gerüchte, dass die auf kommerziell machen wollen und deshalb die freie Version absichtlich schlecht warten.

Durch Zufall bin ich nun darauf gekommen, dass es deshalb vor einigen Jahren einen Fork von Gitea gab, namens Forgejo. Man sieht dem deutlich an, dass es auf demselben Code beruht(e), Nicht ganz identisch, mir ist aufgefallen, dass Gitea einen terraform-Status-Speicher anbietet und Forgejo nicht, was für mich interessant wäre. Es heißt aber, dass Forgejo zuverlässiger gewartet werde, und der Berliner Codeberg e.V. dahinter stehe.

Ob das stimmt und wie nachhaltig das ist oder wieder eine Vereinsmeierei daraus wird – wer weiß. Und bei Code aus Deutschland bin ich inzwischen auch vorsichtig, es ist alles zu politisiert und unterlaufen in diesem Land. Das könnte auf Angriffe hinauslaufen. Und wer über das Build-Tool angreift, der hat gleich gewonnen.

Von beiden, Gitea und Forgejo, gibt es auch Docker-images. Unter podman hat auch das rootless-Image von Gitea nicht auf Anhieb funktioniert, während Forgejo direkt funktioniert hat.

So richtig gefällt mir das leider alles nicht. Alles hat irgendwo irgendwelche Probleme.

Ich neige aber dazu, auf Forgejo oder Gitea zu setzen, weil die am Kompaktesten sind und – abgesehen von den gruseligen github-Actions, die irgendwelche fremden Skripte laden – eigentlich genau das tun, was ich will und, es auch so tun, wie ich es will. Immerhin haben diese github-Actions, die auch Gitea und Forgejo verwenden, den Vorteil, dass sie ein gewisser Standard sind, und man deshalb ohne wesentliche Probleme zwischen github, Gitea und Forgejo hin- und herwechseln kann. Außerdem gibt es mit nektos/act ein Kommandozeilentool, um diese Actions lokal zu entwickeln, zu testen, auszuführen (und wenn ich das richtig gelesen habe, verwenden die Runner von Gitea und Forgejo auch dieses act).

Glücklich bin ich damit nicht, aber es ist zumindest mal ein Ansatz.

Gut wäre, wenn Gitea und Forgejo auch die Pipelines von gitlab implementieren würden. Auch da gibt es Standalone-Implementierungen.

Ich denke, ich werde es mal mit Forgejo probieren. Gitea hätte mir zwar auch gefallen, aber deren Art und Weise, Nutzer über längere Zeit auf einem kaputten Paket hängen zu lassen, obwohl das Problem erkannt und behoben ist, halte ich für produktiv unbrauchbar.