Unsere Rechenleistung gehört nicht uns
Mit Github Actions mieten wir die Runner von Microsoft. Sie sind langsam, haben begrenzte Ressourcen, können nicht sinnvoll angepasst werden und liefern uns der Kapazitätsplanung von Github aus. Wer eine leistungsstarke Maschine für einen großen Build braucht, kann für einen größeren Runner bezahlen – zu Preisen, die ihm eine Kalendereinladung von der Finanzabteilung mit dem Titel "Wir müssen reden" einbringen. Über die Umgebung hat er oder sie trotzdem keine Kontrolle.
Und woran merkt man nun, dass die Runner von Github schlecht sind? Daran, dass es etliche Unternehmen gibt, die nur das Produkt "Github Actions ohne schlechte Runner" anbieten. Namespace, Blacksmith, Actuated, Runs-on, Buildjet – mindestens ein halbes Dutzend Start-ups haben als einziges Ziel, das Problem der Langsamkeit von Github Actions zu lösen.
Ihr Verkaufsargument lautet grob gesagt: "Ihr könnt eure Workflows behalten, wir sorgen dafür, dass sie nicht ewig dauern." Die Tatsache, dass das ein tragfähiges Geschäftsmodell ist, dass mehrere Unternehmen davon leben können, dass die Standardrechenleistung des weltweit beliebtesten CI-Systems unzureichend ist, sagt eigentlich schon alles.
Zugegeben: Man kann eigene Runner in Github Actions einbinden. Es gibt selbstgehostete Runner. Man kann eigene Maschinen einrichten, Nix installieren und die Umgebung nach den eigenen Wünschen konfigurieren. Das löst tatsächlich das Rechenleistungsproblem.
Immer noch dieselbe alte Karre
Die Builds werden schneller, die Caches warm. Aber man muss immer noch Github-Actions-YAML schreiben, sich immer noch mit der Ausdruckssyntax, dem Berechtigungsmodell, dem Marketplace und dem Log-Viewer herumschlagen, der den Browser zum Absturz bringt. Man hat den Motor aufgerüstet, fährt aber immer noch das alte Auto, das in Flammen aufgeht, wenn man das Radio anschaltet.
Wahrscheinlich wurde Github Actions mit den besten Absichten entwickelt. Die Entwickler wollten sicherlich für eine gute Developer Experience sorgen. Aber inzwischen gehört das Produkt Microsoft – jenem Unternehmen, in das ehrgeizige Tools hinwandern, um dort eingelagert zu werden.
Die ursprünglichen Entwickler wurden längst in andere Abteilungen versetzt oder zu Produktmanagern degradiert. Ihre Vision, falls es überhaupt eine gab, wurde begraben. Legt man während eines besonders langsamen Builds das Ohr auf den Boden und lauscht, kann man unter den Dielen ihr Herz noch leise schlagen hören.
Die kleinen Dinge
Manche Dinge erscheinen klein, summieren sich aber zu einem überzeugenden Argument dafür, einfach ins Wasser zu gehen. Das Meer kennt kein YAML. Das Meer verlangt kein GITHUB_TOKEN.
Die Aktion "actions/cache" ist reine Zeitverschwendung. Cache-Schlüssel sind verwirrend, Cache-Fehler bleiben unbemerkt und die Cache-Freigabe ist undurchsichtig. Man verbringt mehr Zeit mit der Fehlerbehebung beim Caching, als man durch den Cache an Zeit gewinnt.
Wiederverwendbare Workflows lassen sich nicht über eine bestimmte Tiefe hinaus verschachteln, können nicht sauber auf den Kontext des aufrufenden Workflows zugreifen und befinden sich in YAML-Dateien, die sich unmöglich isoliert testen lassen.
Irgendwann muss man sich mal hinsetzen und über die Entscheidungen nachdenken, die einen dazu geführt haben, ein verteiltes System in YAML zu schreiben. Dieses Nachdenken verändert einen, man wird nie wieder sein, wer man war: ein Mensch, der nicht wusste, was ein workflow_call-Trigger ist. Ein glücklicher Mensch.
Das GITHUB_TOKEN-Berechtigungsmodell ist ein Labyrinth. permissions: write-all ist ein Hammer, fein abgestufte Berechtigungen sind ein Puzzle, und die Interaktion zwischen Repository-Einstellungen, Workflow-Einstellungen und Einstellungen auf Job-Ebene entfacht den Wunsch, sich einfach nur zu verkriechen.
- Anzeige Hier geht es zum Handbuch für Softwareentwickler bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.