Der Schmerz mit GitHub Actions

 (feldera.com)
2 Punkte von GN⁺ 2025-03-21 | 1 Kommentare | Auf WhatsApp teilen

  • Probleme mit GitHub Actions

    • In letzter Zeit wurde viel Zeit darauf verwendet, CI-Skripte mit GitHub Actions neu zu schreiben. Zuvor wurde Earthly verwendet, doch da es eingestellt wurde, ging es zurück zu GitHub Actions.
    • CI ist komplex und umfasst eine Merge Queue, mehrere Runner, Rust-Builds, Docker-Images, Integrationstests und mehr. Bei jedem Merge eines PR wird viel CI-Zeit verbraucht.
    • Gute Softwarepraktiken erfordern, dass alle Tests bestehen, kleine Fehler automatisch korrigiert werden und die getesteten Artefakte mit dem Release identisch sind. GitHub Actions macht das möglich, aber die Konfiguration ist komplex und inkonsistent.

  • Status Checks und Merge Queue

    • Die Merge Queue von GitHub rebased PRs auf den Main-Branch und führt danach CI aus. CI muss jedoch sowohl vor als auch nach dem Einreihen in die Queue ausgeführt werden, und das einzurichten ist schwierig.
    • Die Lösung besteht darin, in beiden Phasen denselben Job-Namen zu setzen. Dadurch müssen beide Phasen erfolgreich sein.

  • Sicherheitsprobleme

    • Kürzlich wurde eine populäre GitHub Action kompromittiert. Als Gegenmaßnahme wurde empfohlen, Abhängigkeiten per Hash zu pinnen, aber die meisten Nutzer tun das nicht.
    • Das Sicherheitsmodell von GitHub ist komplex und schwer zu verstehen. Die Standardberechtigungen für GITHUB_TOKEN lassen sich festlegen, aber wie man Berechtigungen entzieht, ist nicht eindeutig.
    • Workflow-Berechtigungen hängen nicht von der Action selbst ab, und es wirkt merkwürdig, Berechtigungen im Code zu erhöhen.

  • Die Kombination aus Docker und GitHub Actions

    • In GitHub Actions lassen sich Jobs innerhalb eines Containers ausführen, aber dabei treten Probleme wie Dateiberechtigungen und ein geänderter Speicherort des $HOME-Verzeichnisses auf.
    • Das Container-Feld hat viele Einschränkungen, sodass es nicht möglich ist, den Entrypoint zu überschreiben oder nur einige Schritte innerhalb des Containers auszuführen.

  • Workflow-Entwicklung in YAML

    • Logik in YAML zu schreiben kann komplex werden und ist fehleranfällig. Mit der RustRover-IDE wurden einige Prüfungen durchgeführt, doch bessere statische Prüfungen sind nötig.
    • Lokales Testen ist schwierig, sodass wiederholt Commits erstellt und gepusht werden müssen, bis CI in einem separaten, identischen Repository funktioniert.
    • Workflows sollten klein gehalten und Artefakte hochgeladen werden, damit sie in anderen Workflows wiederverwendet werden können. Beim Herunterladen von Artefakten ist jedoch ein Token erforderlich.

  • Fazit

    • Mit dem neuen CI-Skript wurde die Merge-Zeit deutlich verkürzt, doch die Einrichtung bleibt komplex und das Debugging schwierig. Innovation ist nötig.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-03-21
Hacker-News-Kommentare

  • Es gibt zwar die Meinung, dass GitLab besser ist, aber auch GitLab hat auf andere Weise Probleme

    • Nachdem ich mehrere CI-Tools verwendet habe, halte ich es für wichtig, möglichst viel CI-Logik im eigenen Code zu schreiben
    • Man sollte darin investieren, Pipelines lokal auf Entwicklerrechnern ausführen zu können
    • YAML sollte man möglichst vermeiden
    • Man sollte sich nicht auf neue, durch VC finanzierte Tools verlassen
    • Nach Möglichkeit sollte man eigene Runner verwenden und On-Premises betreiben

  • Es ist interessant, dass GitHub Actions und DevOps so breit kritisiert werden

    • Das Einrichten und Testen kann mühsam sein, aber wenn es einmal läuft, fasst man es kaum noch an
    • Abgesehen von Updates der Node-Version habe ich die Workflows in 4 Jahren fast nicht geändert
    • Ich bin persönlich zufrieden damit

  • Ich habe GitLab verwendet und bin dann zu GitHub gewechselt, war aber enttäuscht

    • GitHub Actions wirkt im Vergleich zu GitLab deutlich unterlegen
    • Wenn ich ein Unternehmen betreiben würde, würde ich GitLab wählen

  • Ein Feedback-Loop von 30–60 Sekunden ist das Schlimmste

    • Ich habe versucht, die GHA-Umgebung lokal nachzubilden, aber das war unmöglich
    • Durch kleine Fehler geht viel Zeit verloren

  • Ich möchte nicht, dass CI den Code automatisch verändert

    • Kleinere Prüfungen sollten als pre-commit hook ausgeführt werden

  • Es ist enttäuschend, dass die Weiterentwicklung von GitHub Actions stehen geblieben zu sein scheint

    • Schade, dass die Entwicklung von Earthly und Dagger eingestellt wurde
    • Nach einer Bewertung von Depot.dev scheint ein sehr kluges Team das Problem gut gelöst zu haben

  • GitHub Actions verleitet dazu, Container als Installationsskripte zu missbrauchen

    • In Workflows geht viel Zeit für das Ausführen von Installern drauf

  • Es ist wichtig, das richtige Tool zu wählen

    • GitHub Actions eignet sich für einfache Aufgaben, aber nicht für komplexe

  • Wegen Sicherheitsproblemen bei GitHub Action sollte man Abhängigkeiten per Hash festschreiben

    • Mit Hashes ist es deutlich sicherer

  • GitHub Actions hat viele Probleme

    • 10-GB-Cache-Limit, Parallelitätsbeschränkungen je nach Runner-Typ, hohe Kosten usw.
    • Depot.dev versucht, GitHub Actions schneller zu machen und die Probleme zu beheben
    • Docker-Image-Builds werden beschleunigt und Runner optimiert, sodass Jobs sehr schnell werden
    • GitHub Actions ist beliebt, hat aber viel Raum für Verbesserungen