Wann sich ein eigener GitHub-Runner lohnt
- Matt
Die Pipeline für diesen Blog läuft auf GitHub-eigenen Runnern und braucht dafür jedes Mal knapp zwei Minuten, von denen gut die Hälfte auf das Einrichten von Ruby und das Wiederherstellen der Gems entfällt. Bei einem Blog ist das egal. Bei einem Projekt, das zwanzigmal am Tag baut, summiert es sich.
Ein selbstgehosteter Runner ist schnell eingerichtet: Archiv herunterladen, config.sh mit einem Token aus den Repository-Einstellungen ausführen, als Dienst registrieren. Der Reiz liegt darin, dass die Umgebung bestehen bleibt. Kein Neuinstallieren von SDKs, kein erneutes Herunterladen der Abhängigkeiten, und der Docker-Cache ist noch warm.
Was dagegen spricht
Der Punkt, der in den meisten Anleitungen zu kurz kommt: Bei einem öffentlichen Repository ist ein selbstgehosteter Runner ein Sicherheitsproblem. Jeder kann einen Pull Request stellen, und der Workflow, der darauf anspringt, führt fremden Code auf der eigenen Maschine aus. GitHub warnt davor ausdrücklich. Für private Repositories ist es unkritisch, für öffentliche braucht es mindestens eine Freigabepflicht für Beiträge von außen.
Dazu kommt die Wartung, die man gern unterschätzt. Der Runner aktualisiert sich selbst, das Betriebssystem darunter nicht. Und das Angenehmste an gehosteten Runnern, nämlich dass jeder Lauf in einer frischen Umgebung startet, gibt man auf. Ein Build, der nur wegen eines Restes aus dem vorherigen Lauf durchgeht, ist eine unangenehme Fehlerklasse. Man findet sie erst, wenn jemand anderes das Projekt baut.
Mein Fazit
Für private Repositories mit häufigen Builds und großen Abhängigkeiten lohnt es sich, besonders wenn ohnehin ein Rechner durchläuft. Für alles Öffentliche und für gelegentliche Builds bleibe ich bei den gehosteten Runnern. Zwei Minuten Wartezeit sind billiger als eine kompromittierte Maschine im eigenen Netz.