In der Welt der Softwareentwicklung gewinnt die Automatisierung immer mehr an Bedeutung. Kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) sind heute unverzichtbare Bestandteile moderner DevOps-Strategien. Eine der bekanntesten Plattformen für CI/CD ist ohne Zweifel GitHub Actions, doch nicht jeder möchte seine Repositories und Pipelines in die Cloud verlagern. Hier kommt Gitea Actions ins Spiel – eine moderne, selbstgehostete CI/CD-Lösung, die besonders für Entwickler und kleine Teams interessant ist, die eine leichte und kosteneffiziente Alternative zu großen Plattformen suchen. Gitea ist bereits lange als leichtgewichtige, selbstgehostete Git-Plattform bekannt, die sich durch ihre geringe Systemressourcen-Anforderung auszeichnet. Sie bietet eine solide Alternative zu umfangreichen Lösungen wie GitLab und überzeugt vor allem Nutzer, die einfache und zuverlässige Git-Verwaltung ohne unnötigen Ballast wünschen.
Seit 2023 wurde mit Gitea Actions ein neues Feature eingeführt, das die CI/CD-Funktionalität direkt integriert und dabei größtenteils kompatibel mit GitHub Actions ist. Dieses Feature ermöglicht es, vertraute Workflows auf der eigenen Infrastruktur auszuführen, ohne auf die Vorzüge der GitHub-Ökosystems verzichten zu müssen. Gitea Actions basiert auf einem cleveren Konzept: Die Implementierung verwendet das Open-Source-Tool nektos/act, welches GitHub Actions lokal ausführt und vor allem zum Testen und Debuggen von Workflows eingesetzt wird. Das Gitea-Team hat darauf aufbauend act_runner entwickelt – einen Koordinator, der sich mit der Gitea-Instanz verbindet und die Workflows über einzelne act-Instanzen ausführt. Ein weiterer spannender Aspekt ist die Integration mit den GitHub Actions APIs, die so umgeleitet werden, dass Gitea als vollwertiger Ersatz fungiert.
Trotzdem gibt es einige Einschränkungen, etwa in Bezug auf Berechtigungen oder den Umgang mit Container-Images im eigenen Docker-Registry. Die Einrichtung von Gitea Actions gestaltet sich für Nutzer, die bereits Erfahrung mit Docker haben, recht einfach. Ein eigener Runner kann als Docker-Container direkt auf dem Host gehostet werden. Vorteilhaft ist hierbei die Möglichkeit, Runner spezifisch für Instanz, Organisation oder Repository zu konfigurieren. Die gängige Praxis sieht vor, dass der Runner mithilfe eines sogenannten Docker-in-Docker (DinD)-Containers ausgeführt wird. Obwohl dies gewisse Sicherheitsaspekte erfordert, wie die Vergabe privilegierter Rechte, bietet dieses Setup eine isolierte Umgebung, die zugleich flexibel Workflows mit Docker-Containern ausführt. Die Trennung des Netzwerks für Runner und Gitea-Instanz erhöht dabei die Sicherheit, indem direkte Netzwerkkommunikation eingeschränkt wird und alle Interaktionen über das Kanten-Routing erfolgen.
Ein großer Vorteil von Gitea Actions ist die Fähigkeit, nahtlos GitHub Actions Workflows zu übernehmen. Für Nutzer, die bereits in der GitHub-Welt zuhause sind, bedeutet dies kaum Umstellungsaufwand. Viele GitHub Actions funktionieren unmittelbar mit Gitea Actions, sodass die Pfade für die Migration bereits geebnet sind. Dennoch gibt es gewisse Anpassungen, besonders in Bezug auf Umgebungsvariablen. Gitea empfiehlt das Präfix GITEA_ anstelle von GITHUB_, aber aus pragmatischen Gründen behalten viele Anwender das original GitHub-Präfix bei, um Kompatibilitätsprobleme zu vermeiden. Eine Herausforderung ist derzeit noch die Rechtevergabe des Runner-Tokens, welches standardmäßig nur Leseberechtigungen für das Repository besitzt. Im Gegensatz zu GitHub, wo das Runner-Token weitergehende Rechte haben kann, erlaubt Gitea die Nutzung des integrierten Docker-Registries nicht über das Runner-Token.
Um Images in die Registry zu pushen, ist es daher erforderlich, einen persönlichen Access Token mit entsprechenden Rechten zu erstellen und als Secret im Workflow zu verwenden. Dies bildet zwar eine zusätzliche Hürde, sorgt aber auch für erhöhten Schutz vor Missbrauch in Multi-User-Setups. Im Zusammenhang mit Submodulen, speziell bei privaten Repositories, zeigt sich Gitea Actions ebenfalls robust. Der Workflow Checkout verwendet HTTPS mit persönlichem Token statt SSH-Schlüsseln, was sicherer und einfacher in automatisierten Umgebungen ist. Die Verwendung der Git-Konfiguration „insteadOf“ ermöglicht es, das übliche SSH-Protokoll durch HTTPS zu ersetzen, um damit Zugriffshürden zu überwinden. Bei geschlossenem System mit der Einstellung REQUIRE_SIGNIN_VIEW wird somit gewährleistet, dass alle Repository-Inhalte nur angemeldeten Benutzern zugänglich sind und die Workflow-Ausführung dennoch reibungslos funktioniert.
Die Handhabung großer Dateien über Git Large File Storage (LFS) verkompliziert die Sache jedoch etwas. Git LFS verwendet für den Download der eigentlichen Binärdateien einen separaten Autorisierungstoken, der von der Repository-Zugriffssteuerung getrennt ist. In Gitea Actions kommt es dabei zu Problemen, da die von GitHub Actions standardmäßig gesetzten HTTP-Header nicht in gleicher Weise funktionieren und die LFS-Tokenübermittlung behindert wird. Eine von Chris Liebär entwickelte Lösung ersetzt den git-Befehl temporär durch einen Wrapper, der die problematischen Aufrufe abfängt und korrigiert. Dieses Hilfsmittel namens gitea-actions-fix sorgt dafür, dass das Checkout mit Submodulen und LFS wieder zuverlässig läuft und macht den Weg frei für umfangreiche Repositorys mit großen Binärdateien. Sicherheit und Isolation sind zentrale Themen bei selbstgehosteten CI/CD-Systemen.
In Gitea Actions laufen die einzelnen Workflow-Runs in separaten Docker-Containern, die über den DinD-Daemon gemeinsame Ressourcen nutzen. Die rootless-Variante reduziert dabei das Risiko von Container-Eskapaden, jedoch bleibt eine potentielle Sicherheitslücke in der privilegierten DinD-Komponente. Auf der anderen Seite hat der Nutzer volle Kontrolle über die ausgeführten Aktionen, was insbesondere bei Einzelanwendern und vertrauenswürdigen Teams ein großer Vorteil ist. Bei mehreren Nutzern teilen sich die Runner jedoch bestimmte Caches, was theoretisch zu Datenlecks oder unbeabsichtigtem Zugriff führen kann. Die beste Praxis empfiehlt daher, für jeden Benutzer eigene Runner bereitzustellen oder im Bewusstsein zu arbeiten, dass ein gewisser Zugriff auf andere Projekte besteht. Im Vergleich zu anderen CI/CD-Systemen wie Drone oder GitLab CI hebt sich Gitea durch sein schlankes Konzept und die GitHub Actions-Kompatibilität hervor.
Drone verfügt zwar über eine gute Integration mit Gitea, setzt aber meist auf reine Docker-Container-Schritte ohne ein großes Ökosystem von Aktionen. GitLab CI ist ebenfalls mächtig und gut durchdacht, hat aber den Nachteil, mit seinen vielen Features relativ ressourcenintensiv und manchmal langsam zu sein. Gitea Actions punktet besonders durch die Wiederverwendung etablierter GitHub Actions und die einfache Skalierbarkeit durch Docker-Umgebungen. Für alle, die bereits Gitea als Git-Hosting nutzen, bietet Gitea Actions einen natürlichen und bequemen Einstieg in automatisierte Workflows mit minimalen Anpassungen. Die Kombination aus Selbstbestimmung, ohne Limitierungen bei Laufzeiten oder Speicherplatz, verbunden mit der gewohnten GitHub Actions Syntax, macht Gitea Actions zu einer zukunftsfähigen Lösung – vor allem dann, wenn Datenschutz, Kostenkontrolle und Infrastrukturhoheit im Vordergrund stehen. Ein interessantes Nebenprodukt in der Gitea-Community ist Forgejo, ein Fork von Gitea.
Zwar verspricht Forgejo neue Funktionen und Unabhängigkeit, jedoch sind noch nicht alle Kompatibilitäten gewährleistet und die Community sowie viele Projekte sind weiterhin größtenteils auf Gitea fokussiert. Für die meisten Nutzer bleibt Gitea daher die erste Wahl, zumal die Entwicklung konsequent voranschreitet und sich die Funktionen – insbesondere im Bereich CI/CD mit Gitea Actions – stetig verbessern. Abschließend lässt sich sagen, dass Gitea Actions eine potente und vor allem pragmatische Alternative für Entwickler bietet, die ihre Pipelines auf der eigenen Infrastruktur betreiben möchten. Es erlaubt die Nutzung bestehender GitHub Actions Workflows, bleibt dabei offen, leichtgewichtig und bietet eine große Flexibilität hinsichtlich Konfiguration und Betrieb.
Wer den Aufwand und die Herausforderungen nicht scheut, profitiert von einer CI/CD-Lösung, die kein Drittanbieter in der Cloud benötigt, keine störenden Limits setzt und gleichzeitig den Anschluss an die größte Actions-Community der Welt ermöglicht. Mit dem zunehmenden Interesse an Datenschutz und der Kontrolle über eigene Codebasen dürfte Gitea Actions in den kommenden Jahren weiter an Bedeutung gewinnen. Für Einzelentwickler sowie kleine bis mittlere Teams ist es heute bereits eine vollwertige Alternative, die zudem hilft, Kosten und Abhängigkeiten bei der Softwareentwicklung zu reduzieren.
