Selbstgehostete CI/CD mit Forgejo Runner auf Codeberg

Warum einen eigenen CI/CD-Runner hosten?

Codeberg ist eine starke GitHub-Alternative. Die Plattform basiert auf Forgejo und wird von einem gemeinnützigen Verein betrieben. Wer Wert auf Datenschutz legt, findet hier eine gute Lösung. Allerdings stoßen die geteilten Runner an ihre Grenzen, wenn viele Nutzer gleichzeitig CI/CD-Jobs ausführen.

Die Antwort liegt darin, einen eigenen Forgejo-Runner zu betreiben. Der Runner verbindet sich selbstständig mit Codeberg. Er braucht keine offenen Ports, sondern funktioniert auf einem VPS, einem Heimserver oder sogar dem Laptop.

Wie der Runner aufgebaut ist

Ein Forgejo-Runner nimmt Jobs von Codeberg entgegen und führt sie aus. Aus Sicherheitsgründen läuft er in einem isolierten Docker-Umfeld. Mit Docker-in-Docker bleibt der Host-Docker-Daemon unberührt. Das schützt das System vor unerwünschtem Zugriff.

Docker Compose einrichten

Das Setup besteht aus zwei Containern:

version: '3.8'

services:
  docker-in-docker:
    image: docker:dind
    container_name: 'docker_dind'
    privileged: 'true'
    command: ['dockerd', '-H', 'tcp://0.0.0.0:2375', '--tls=false']
    restart: 'unless-stopped'

  runner:
    image: 'data.forgejo.org/forgejo/runner:12'
    links:
      - docker-in-docker
    depends_on:
      docker-in-docker:
        condition: service_started
    container_name: 'runner'
    environment:
      DOCKER_HOST: tcp://docker-in-docker:2375
    user: 1001:1001
    volumes:
      - ./data:/data
    restart: 'unless-stopped'
    command: 'forgejo-runner daemon --config runner-config.yml'

Der erste Container stellt eine isolierte Docker-Umgebung bereit. Der zweite Container ist der eigentliche Runner.

System vorbereiten

Vor dem Start der Container muss die Verzeichnisstruktur mit passenden Berechtigungen angelegt werden. Am besten legt man alles unter /opt/forgejo-runner an und führt folgende Befehle aus:

cd /opt/forgejo-runner
mkdir -p data/.cache
chown -R 1001:1001 data
chmod 775 data/.cache
chmod g+s data/.cache

Anschließend erzeugt man die Standardkonfiguration:

sudo sh -c 'docker run --rm data.forgejo.org/forgejo/runner:12 forgejo-runner generate-config > data/runner-config.yml'

Runner bei Codeberg registrieren

Jetzt geht es um die Anbindung an Codeberg. Im Account oder in der Organisation unter Actions → Runners kann man einen neuen Runner anlegen. Nach dem Vergeben eines Namen erhält man ein UUID und ein Token. Beide Werte sind wichtig und sollten sofort festgehalten werden.

Codeberg gibt anschließend die benötigten YAML-Werte vor.

Labels und Kapazität einstellen

In der Datei runner-config.yml sind zwei Punkte besonders wichtig:

1. Server-Konfiguration
Die von Codeberg übergebenen Zugangsdaten werden hier eingetragen.

2. Labels
Labels bestimmen, welche Jobs der Runner annehmen darf. Mit der Syntax [Workflow Label]:[Execution Method]://[Environment] lässt sich genau festlegen, welche Container-Images zur Verfügung stehen.

Die meisten Entwickler verwenden Labels wie ubuntu-latest oder ubuntu-22.04 und binden entsprechende Node- oder andere Images an.

Optional: Mehr Kapazität
Wer mehrere Jobs parallel laufen lassen möchte, erhöht den Wert capacity – zum Beispiel auf 4.

In Betrieb nehmen

Mit docker-compose up -d lässt sich das Setup starten. Anschließend kann man die Logs mit docker-compose logs -f runner kontrollieren. Werden keine Fehler angezeigt, verbindet sich der Runner erfolgreich mit Codeberg.

Was sich dadurch verbessert

Ein selbst gehosteter Runner bringt mehrere Vorteile:

• Keine Wartezeiten mehr in der Warteschleife
• Mehr Kontrolle über das Setup und die verwendeten Abhängigkeiten
• Weniger Last auf Codebergs geteilten Runnern
• Bessere Datenschutzbedingungen, weil Logs auf dem eigenen System bleiben
• Möglichkeit, je nach Bedarf aufzurüsten

Fazit

Wer Codeberg nutzt, kann mit einem selbst gehosteten Runner die CI/CD-Infrastruktur verbessern. Das Projekt lässt sich leicht in einem Nachmittag umsetzen und wächst mit den Anforderungen. Wer noch auf GitHub unterstützt, findet hier eine einfache Möglichkeit, mehr Kontrolle über die CI/CD-Pipeline zu zu gewinnen.