Forgejo hat sich als flexible und quelloffene Plattform für Git-Repository-Management etabliert, die insbesondere für Anwender attraktiv ist, die personalisierte oder private CI/CD-Lösungen bevorzugen. Eine der zentralen Funktionen, die Forgejo besonders leistungsfähig machen, sind die sogenannten Actions – automatisierte Workflows, die Softwareprozesse effizient gestalten. Die Konfiguration von Forgejo Actions bietet ein hohes Maß an Flexibilität und Kontrolle, ermöglicht aber auch eine ressourcenschonende sowie sichere Umsetzung von Continuous Integration und Deployment auf eigenen Servern. Die Einrichtung einer Forgejo Runner-Instanz ist der erste wichtige Schritt, um Actions auszuführen. Im Gegensatz zu herkömmlichen Webhook-basierten Systemen ermöglicht ein Runner das direkte Ausführen von Aktionen auf einem eigenen Rechner oder Server.
Ein beliebter Ansatz ist die Installation des Runners über eine OCI-Image-basierte Methode, welche sich durch Einfachheit und Schnelligkeit auszeichnet. Hierbei wird zunächst ein spezieller Nutzer (forgejo-runner) angelegt, der als Laufzeitumgebung für die Runner-Services dient. Die für den Runner notwendigen Verzeichnisse und Konfigurationsdateien werden automatisiert angelegt. Besonders wichtig ist das Erstellen einer .runner-Datei, die mit einem Geheimnis (Secret) gesichert wird, das die Verbindung zwischen Runner und Forgejo-Server authentifiziert.
Die Registrierung erfolgt anschließend über die Forgejo-CLI mit spezifizierten Parametern für den Namen des Runners und das Secret. Es ist auch möglich, den Runner über die Weboberfläche von Forgejo zu registrieren, was insbesondere dann empfehlenswert ist, wenn mehrere Runner verwaltet werden sollen. Der Nachteil ist, dass dann die vorgefertigte setup-runner.sh-Skriptmodifikation notwendig ist, um das Secret anzupassen. Ein zentraler Baustein für die Ausführung von Jobs sind die Container, innerhalb derer die Aktionen abgespielt werden.
Hier bewährt sich eine Docker-in-Docker-Strategie (dind), um isolierte Containerwelten mit eigener Daemonkonfiguration bereitstellen zu können. Ursprünglich wurde der Docker-Daemon über einen TCP-Port angesprochen, jedoch zeigte sich bei Praxisversuchen, dass dies zu Problemen führt, insbesondere wenn verschachtelte Docker-Container erzeugt werden. Die Performance leidet und die Komplexität steigt unnötig. Daher empfiehlt es sich, stattdessen einen Unix-Socket zu verwenden, der gemeinsam als Volume mit den Runner-Containern geteilt wird. Diese Methode erlaubt einen direkten Zugriff auf den Docker-Daemon, ohne dabei Netzwerk-Overhead oder Privilegien zu strapazieren.
Die Sicherheit ist bei solchen Konfigurationen ein relevantes Thema, da der Zugriff auf den Docker-Socket einem Root-Zugriff auf den Hostsystembereich gleichkommt. Für private oder Home-Server mit vertrauenswürdigem Nutzer stellt dies jedoch meist kein großes Risiko dar. Wenn mehr Sicherheit erforderlich ist, kann alternativ ein separater Docker-Daemon eigens für die Jobausführung gestartet werden, der ebenfalls über einen Unix-Socket kommuniziert. So lassen sich Ressourcen trennen und potenzielle Sicherheitslücken einkapseln. Das Herzstück der Service-Orchestrierung ist häufig eine Docker-Compose-Datei, die alle relevanten Container sowie deren Volumes, Umgebungsvariablen und Startbefehle definiert.
In der hier beschriebenen Konfiguration sind zwei Hauptdienste definiert: ein dind-Service und der Runner selbst. Durch gezieltes Konfigurieren von Nutzer- und Gruppenzugriffen wird sichergestellt, dass der Runner den Docker-Daemon verwenden kann, ohne unnötige Rechte zu erlangen. Zudem verfügt der Runner über ein angepasstes Konfigurationsfile (config.yaml), das die parallele Ausführung mehrerer Jobs ermöglicht und das Bereitstellen des Docker-Sockets in den Job-Containern erlaubt. Ein weiterer wichtiger Baustein ist die Pflege eigener Organisationen und Gruppen auf dem Forgejo-Server.
Neben der Verwaltung der eigentlichen Softwareprojekte können hier auch eigene Actions und Images gehostet sowie Remote-Repositories gespiegelt werden. Gerade durch das Spiegeln entfernter Actions und Container-Images wird die Stabilität und Geschwindigkeit der Workflows signifikant verbessert. Die Spiegelung reduziert Abhängigkeiten vom Netzwerk, verringert potenzielle Ausfallzeiten und erhöht die Sicherheit durch Kontrolle der verwendeten Komponenten. In der Praxis bedeutet das, dass beispielsweise Aktionen wie der Checkout einer Repository-Version, der Login bei Docker-Registries oder der Aufbau von Buildx-Umgebungen lokal vorgehalten werden. Darüber hinaus können selbst erstellte, maßgeschneiderte Docker-Images genutzt werden, die alle nötigen Werkzeuge bereits integriert haben.
Das entlastet die CI/CD-Jobs erheblich und beschleunigt die Durchlaufzeiten. Die Verwaltung der Zugriffsrechte auf Container-Registries erfolgt über Token, die mit passenden Berechtigungen ausgestattet sind. Typischerweise wird ein Nutzer mit Schreibrechten auf die entsprechende Organisation definiert und dessen Token als sogenannter Secret-Wert in den Forgejo-Aktionen hinterlegt. Ebenso werden Umgebungsvariablen definiert, welche innerhalb der Workflows zur Authentifizierung verwendet werden können. Der lokale Login über Docker ist ebenfalls ein wichtiger Schritt, um Images manuell zu pushen oder für erste Tests.
Das Bilden separater Projekte für eigene Images und Spiegelungen schafft eine saubere und übersichtliche Struktur. Im Images-Projekt werden beispielsweise Dockerfiles für verschiedene Basis-Images sowie Aktionen für den automatischen Bau und das Pushen umgesetzt. Dabei bietet sich eine Monorepo-Strategie an, bei der mehrere Images in eigenen Unterordnern gehalten werden. Automatisierte Workflows wie build-image-from-tag prüfen dabei anhand von Tag-Formaten, ob und welche Images gebaut werden sollen. Die flexiblen Bedingungen innerhalb der Workflows helfen dabei, ungewollte Builds zu vermeiden und Ressourcen gezielt einzusetzen.
Ein wesentlicher Vorteil der Container-Build-Workflows besteht darin, dass kein eigener Docker-Daemon innerhalb des Runner-Containers gestartet werden muss. Stattdessen wird der vorhandene dind-Docker-Daemon genutzt, der per Socket mit dem Runner und dessen Job-Containern geteilt wird. Dies spart Rechenleistung und beschleunigt die Abläufe. Die Build-Push-Actions verwenden zudem Buildargs, um das richtige Registry-Präfix für Images dynamisch einzusetzen, was die Wiederverwendbarkeit und Flexibilität erhöht. Für Versionsmanagement und semantisches Release kommt in dieser Umgebung das Tool multi-semantic-release zum Einsatz, das ähnlich wie klassische Release-Manager durch Tagging und automatische Versionierung Arbeitsabläufe optimiert.
Über Templates wird die Konfiguration dynamisch generiert, was eine einfache Erweiterung für zukünftige Images oder Anpassungen ermöglicht. Nachdem Releases erstellt wurden, werden neue Builds für die jeweiligen Tags automatisch per API-Aufruf getriggert, was einen vollautomatischen Zyklus sicherstellt. Die Spiegelung externer Container-Images erfolgt über das Tool regsync, das mittels konfigurierbarer YAML-Dateien gesteuert werden kann. Der Workflow für die Spiegelung läuft regelmäßig oder bei Änderungen der Konfigurationsdatei und sorgt dafür, dass bestimmte Container-Versionen immer aktuell vorgehalten werden. Besonders nützlich ist hier die Filterung der zu synchronisierenden Tags, um alte oder nicht erwünschte Versionen auszuschließen.
Zusammengefasst bietet die Konfiguration von Forgejo Actions ein sehr anpassbares Umfeld zur Umsetzung leistungsfähiger CI/CD-Pipelines ohne Abhängigkeiten von SaaS-Anbietern. Gerade im privaten oder kleineren professionellen Bereich ermöglicht dies eine kosteneffiziente, sichere und kontrollierte Infrastruktur mit hoher Autonomie. Darüber hinaus ist die Offenheit und Modularität von Forgejo und seinen Actions eine Grundlage für individuell zugeschnittene Prozesse, die mit einem modernen Docker-Nutzungskonzept einen sehr guten Automatisierungsgrad erzielen. Wer auf der Suche nach einer robusten Lösung für die Versionsverwaltung inklusive automatischer Abläufe ist, findet in dieser Kombination eine überzeugende Alternative zu kommerziellen Plattformen. Durch die geschickte Kombination aus Container-Technologien, Spiegel-Organisationen und automatisierten Workflows lässt sich eine moderne Entwicklungsumgebung aufbauen, die zugleich schnell, sicher und leicht wartbar ist.
Die Open-Source-Natur von Forgejo sowie die aktive Community ermöglichen dabei eine stetige Weiterentwicklung und Anpassung an neue Anforderungen und Projektszenarien. Für die Zukunft können Anwender von Forgejo Actions beispielsweise noch weitergehende Integrationen, verbesserte Zugriffskontrollen und tiefere Automatisierungsoptionen erwarten. Zudem eröffnen sich Möglichkeiten, die Infrastruktur durch Monitoring und Notification-Systeme zu erweitern oder plattformübergreifende Arbeitsweisen mit anderen Forgejo-Instanzen aufzubauen. Schnelles Feedback, reproduzierbare Builds und transparente Deployment-Prozesse sind dabei Kernziele, die durch Forgejo Actions bestens unterstützt werden. Der Weg zu einer vollständig selbstverwalteten, skalierbaren und effizienten Continuous-Integration-Umgebung ist mit der beschriebenen Konfiguration gut nachvollziehbar und bietet gleichzeitig genügend Freiräume, um eigene Anpassungen und Erweiterungen zu realisieren.
Insbesondere für Entwickler und Teams, die Wert auf Datenschutz, Unabhängigkeit und Anpassbarkeit legen, stellt Forgejo eine ausgezeichnete Basis dar. Die Kombination aus modernen Containertechnologien und einem flexiblen Actions-System verwandelt einen einfachen Git-Server in eine echte DevOps-Plattform, die allen Bedürfnissen gerecht wird.
