- Geteilte Frustration eines Entwicklers über die langsame Feedback-Schleife und den komplizierten Debugging-Prozess von GitHub Actions
- Im Projekt tmplr wurden über
build.rs mit CUE Dokumente erzeugt, doch mit dem Fehlschlagen des CI-Builds begannen die Probleme
- Von vier Plattformen schlug nur der Build für Linux ARM fehl; Ursache ist das Verhalten von GitHub Actions, bei Cross-Builds x86_64-Binärdateien auf arm64-Runnern zu verbergen
- Die ineffiziente Feedback-Schleife mit 2–3 Minuten pro Test einer einzelnen Änderung wiederholte sich ständig
- Als Lösung wurde
build.rs entfernt und auf ein GNU Makefile umgestellt, um die CI-Logik direkt zu steuern
Hintergrund des Problems
- tmplr ist ein Datei-/Projekt-Scaffolding-Tool, das von Menschen lesbare und schreibbare Template-Dateien verwendet
- In
build.rs wurde CUE genutzt, um README.md, CHANGELOG.md sowie Versions-/Hilfedateien zu erzeugen und so Konsistenz sicherzustellen
- Die eigentliche Arbeit war in etwa 1,5 Stunden erledigt, und ein dazugehöriger Artikel war ebenfalls bereits geschrieben
- Lokal funktionierte alles problemlos, doch in der CI-Umgebung von GitHub Actions schlug der Build fehl, weil die CUE-Binärdatei nicht installiert war
Ursache des Build-Fehlers
- Von vier Plattformen (Linux ARM, macOS ARM, Linux x86_64, macOS x86_64) trat nur auf Linux ARM der Fehler „command not found“ auf
- Ursache: Matrix-Cross-Builds sind stark isoliert, daher wurde CUE nur auf dem x86_64-Linux-Host und dem macOS-ARM-Host installiert
- macOS kann x86_64-Binärdateien problemlos ausführen
- Linux x86_64 kann x86_64-Binärdateien ebenfalls problemlos ausführen
- GitHub Actions jedoch verbirgt auf arm64-Runnern x86_64-Binärdateien, sodass sie nicht ausgeführt werden können
Ineffiziente Feedback-Schleife
- Zur Problemlösung wurde immer wieder derselbe Ablauf wiederholt:
1. Nach möglichen Lösungswegen suchen
2. ci.yml ändern
3. Committen und pushen (jj squash --ignore-immutable && jj git push)
4. Den Tab „Actions“ öffnen
5. Den neuesten Lauf öffnen
6. Den Linux-ARM-Lauf öffnen
7. Einige Sekunden warten
8. Frustriert sein
9. Wiederholen
- Pro einzelner Änderung vergingen 2–3 Minuten
- Im Idealfall würde GitHub entweder einen voll ausgestatteten lokalen Runner bereitstellen oder eine Möglichkeit bieten, nach dem Push den Fortschritt schnell zu überprüfen
- Etwa eine Funktion wie ein „scratch commit“: eine Möglichkeit, verschiedene Läufe zu testen, ohne die Git-Historie und den Verlauf der Actions-Ausführungen zu verschmutzen
- Eine solche Funktion gibt es derzeit jedoch nicht
Lösung
- Nach 30 Minuten in dieser Schleife wurde abgebrochen
- Es wurde ein bekannter Rat aus dem Internet übernommen: „Lass GitHub Actions nicht die Logik verwalten, sondern steuere die Skripte selbst und lasse Actions diese Skripte nur aufrufen“
build.rs wurde gelöscht (bedauerlich, aber ein notwendiges Opfer)- Alle Generierungsaufgaben wurden in ein GNU Makefile verlagert
- Die erzeugten Dateien wurden ins Repository committed, und die Änderungen an der CI wurden zurückgenommen
- Das Problem war damit gelöst
Fazit
- GitHub Actions ist ein Grund dafür, dass man auf manche guten Dinge verzichten muss
- Beim Debuggen von Runnern oder beim Optimieren des Build-Prozesses geht viel Zeit verloren
- Gleichzeitig gibt es Vorteile wie macOS-Builds, die sich auf anderem Weg nur schwer bekommen lassen
- Natürlich ist auch kein anderes System bekannt, das sich einfacher einrichten lässt als GitHub Actions
> We are all doomed to GitHub Actions. …but at least I dodged the bullet early.
Noch keine Kommentare.