GitHub Actions könnte viel besser sein

• GitHub Actions ist in Sachen Produktivität und Funktionsumfang nützlich, aber beim Schreiben echter Workflows führen verzögertes Debugging, Sicherheitsfehler, fehlende Typen und ein Mangel an offiziellen Actions immer wieder zu Zeitverlust.
• Selbst für kleine Änderungen muss man wiederholt git add; git commit; git push ausführen und Browser-Logs prüfen; in einem Fall waren selbst für einen einfachen Release-Workflow 4 Commits und ein fehlgeschlagener Release nötig.
• ${{... }}-Expansion, pull_request_target, breit gefasste Standardberechtigungen für GITHUB_TOKEN und SHA-Referenzen von Forks sind allesamt sicherheitskritische Punkte, an denen leicht Fehler passieren; besonders eine Fork-SHA kann wie ein Commit aus dem beabsichtigten Repository aussehen.
• Für Action-Inputs gibt es keine type:-Validierung, und auch der unterstützte Umfang unterscheidet sich zwischen workflow_call und workflow_dispatch; statt Array- oder Objekt-Inputs muss man daher CSV-artige Strings oder abgeflachte Inputs selbst verarbeiten.
• Validierung beim Push, Sicherheitsprüfungen zur Laufzeit, eingeschränktere Standard-Token-Rechte in privaten Repositories, strengere Typprüfungen und mehr offizielle oder quasi-offizielle Actions könnten die Zuverlässigkeit von Workflows erhöhen.

---

Nützlich, aber GitHub Actions bremst einen immer wieder aus

• GitHub Actions ist seit 2019 ein Werkzeug, das in professionellen Projekten wie auch in Hobbyprojekten täglich genutzt wird und Produktivität wie Verlässlichkeit stark verbessert hat.
• Auch die Erweiterung des Funktionsumfangs wurde kontinuierlich vorangetrieben.
  • reusable workflows
  • OpenID connect
  • job summaries
  • GitHub Mobile-Integration
• Trotzdem ist es im tatsächlichen Entwicklungsprozess oft eine Ursache für große Frustration und Zeitverlust.

Debugging ist selbst bei kleinen Fehlern viel zu schwergewichtig

• Beim Einrichten eines Release-Workflows gab es einen Fall, in dem zur Behebung kleiner Fehler 4 Commits und 4 fehlgeschlagene Releases nötig waren.
  • ${{ ... }} wurde dort, wo es nötig war, nicht verwendet.
  • Eine needs:-Beziehung wurde vergessen.
• Der aktuelle Debugging-Zyklus umfasst selbst für die Überprüfung eines simplen Fehlers viele Schritte.
  • Man muss aus der Entwicklungsumgebung in den Browser wechseln.
  • Man muss den richtigen Tab finden.
  • Man muss sich durch die Actions-Zusammenfassung und den Statusbildschirm klicken.
  • Man muss gepufferte Konsolen-Logs aktualisieren, um den nächsten Fehler zu finden.
• Selbst bei kleinen Änderungen kann der gesamte Ablauf mehr als 30 Sekunden dauern.

• Verbesserungsrichtung

  • Es sollte eine interaktive Debugging-Shell geben, oder zumindest die Möglichkeit, Workflows nach kleinen Änderungen erneut auszuführen, ohne git add; git commit; git push.
  • Über Repository-Einstellungen sollte es möglich sein, offensichtlich fehlerhafte Workflows bereits beim Push zurückzuweisen.
    • Syntax, die nicht funktionieren kann
    • Verweise auf nicht existierende Jobs oder Steps
    • Fälle, in denen ein Workflow wegen fehlerhaftem YAML stillschweigend gar nicht ausgeführt wird

Sicherheitsfehler passieren viel zu leicht

• In GitHub Actions können von Nutzern geschriebene Workflows unbeabsichtigt leicht verwundbar werden.
• Wenn ${{ ... }}-Expansion in einer Shell oder einem anderen Ausführungskontext verwendet wird und der expandierte Wert benutzerkontrollierter Input ist, kann das zu Code-Injection führen.
  • Im Beispiel wird über inputs.frob Code injiziert, wodurch $MY_IMPORTANT_SECRET offengelegt werden kann.
• pull_request_target ist in nichttrivialen Workflows extrem schwer sicher zu verwenden.
  • Der beabsichtigte Einsatzzweck scheint auf enge Fälle wie das Setzen von Labels oder das Schreiben von Kommentaren bei PRs aus Forks beschränkt zu sein.
  • In der Praxis ist es jedoch wie eine große foot-gun exponiert.
• Auch Berechtigungen auf Workflow- und Job-Ebene werden leicht zu großzügig gesetzt.
  • Die Standardzugriffsrechte des normalen GITHUB_TOKEN sind sehr weitreichend.
  • In Repositories persönlicher Accounts vergisst man oft, die Standardrechte des Tokens zu reduzieren.
  • Weil der genaue benötigte Berechtigungsumfang unklar ist, vergibt man Token-Rechte schnell zu breit.
• Das GitHub-Berechtigungsmodell wird zusätzlich dadurch verwirrend, dass es in die einzelne Achse read/write/none gepresst wird.
  • id-token: write erlaubt das Lesen des OpenID-Connect-Tokens eines Workflows.
  • Manche GET-Operationen für Security Advisories verlangen write, andere dagegen nur read.

Auf SHA gepinnte Actions können mit Fork-Commits verwechselt werden

• Eine Referenz wie actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e muss in Wirklichkeit kein Commit im Repository actions/checkout sein.
• Die betreffende SHA kann ein Commit in einem Fork innerhalb des actions/checkout-Netzwerks sein und durch GitHubs Nutzung von alternates so erscheinen, als gehöre sie zum übergeordneten Repository.
• Ein verwandter Artikel von Chainguard unterteilt das Problem in drei Bereiche.
  • Die SHA-Referenz eines Forks und die SHA-Referenz des Ziel-Repositories sind visuell nicht unterscheidbar.
  • Die GitHub-REST-API unter /repos/{user}/{repo}/commits/{ref} liefert eine JSON-Antwort, die nur auf {user}/{repo} verweist, selbst wenn {ref} nur im Fork existiert.
  • Wenn sich Fork- und Nicht-Fork-SHAs nicht unterscheiden lassen, können Einschränkungen für vertrauenswürdige Quellen in GitHub Actions umgangen werden.
• GitHubs Reaktion bestand bisher im Wesentlichen nur darin, einen zusätzlichen Hinweis in die Dokumentation aufzunehmen.

• Verbesserungsrichtung

  • Es braucht einen paranoid workflow security-Modus, der offensichtlich unsichere Workflows bereits beim Push zurückweist.
  • Ähnlich wie Runtime-Instrumentierung bei AddressSanitizer sollte es möglich sein, sicherheitsgefährdende Muster während der Workflow-Ausführung fehlschlagen zu lassen.
    • Beispiel: In pull_request_target schlägt actions/checkout fehl, wenn ein Ref verwendet wird, der nicht aus dem Ziel-Repository stammt.
  • Auch eine Abschaffung oder Entfernung von pull_request_target könnte geprüft werden.
  • Selbst in persönlichen Repositories sollte sich der Standardumfang von GITHUB_TOKEN restriktiver konfigurieren lassen, wie es bei Organisationen und Enterprises möglich ist.
  • Actions, die per SHA gepinnt sind, deren SHA aber nicht im referenzierten Repository, sondern nur im Fork existiert, sollten standardmäßig abgelehnt werden.

Dem Typsystem fehlen Konsistenz und Ausdruckskraft

• Benutzerdefinierte GitHub Actions können Inputs unter inputs: definieren, aber für Action-Inputs gibt es keine Typdurchsetzung.
• Eine Deklaration wie type: number funktioniert bei Action-Inputs nicht.
• Selbst innerhalb von GitHub Actions wird Typunterstützung nicht konsistent angeboten.
  • workflow_call: Unterstützung für boolean, number, string
  • workflow_dispatch: Unterstützung für boolean, choice, number, string
  • Action-Inputs: keine Typunterstützung
• Selbst dort, wo Typen unterstützt werden, gibt es keine Unterstützung für komplexe Datenstrukturen wie Arrays oder Objekte.
  • Kein Array-Input wie paths: [foo, bar, baz]
  • Kein Objekt-Input mit Hierarchie unter headers:
• Stattdessen verlangen Action-Autoren provisorische Eingabeformate.
  • Eigene CSV-artige Verarbeitung wie paths: foo,bar,baz
  • Abflachung natürlicher Hierarchien wie header-foo, header-baz
• Das ist weder für Wartbarkeit noch für Sicherheit gut.
  • Man muss selbst einen einzelnen flachen Input-Namensraum verwalten.
  • Für komplexe Inputs entsteht faktisch eine beliebige, nicht spezifizierte Minisprache.

• Verbesserungsrichtung

  • Autoren von Actions und Workflows sollten type: überall verwenden können.
  • Auch choice sollte nicht nur auf workflow_dispatch beschränkt sein, sondern überall verfügbar sein.
  • Wo Typen statisch inferiert werden können, sollten Workflow-Änderungen mit falschen Typen bereits beim Push zurückgewiesen werden.
  • Es braucht type: object und type: array.
  • Auch wenn die internen Typen heterogen sein können und die Lösung nicht perfekt wäre, wäre sie besser als der aktuelle Zustand.
  • Bei Bedarf könnte die Übergabe als JSON-serialisierter String erfolgen.
  • GitHub Actions hat bereits die Funktion fromJSON(...).

Offizielle Actions sind direkt mit dem Vertrauen in die Plattform verknüpft

• Im Third-Party-Ökosystem von GitHub Actions gibt es viele hochwertige Actions.
• Darunter liegen die offiziellen, von GitHub gepflegten Actions.
  • Zentrale git-Aufgaben: actions/checkout
  • GitHub-Aufgaben und Repository-Verwaltung: actions/{upload,download}-artifact, actions/cache, actions/stale
  • Unverzichtbares Setup: actions/setup-python, actions/setup-node
• Diese Actions sind allgemein einsetzbar und wichtig, daher ist der Wert offiziell gepflegter Implementierungen hoch.
• Dennoch ist die Zahl offizieller Actions gering, und selbst Aufgaben, die GitHub-Funktionen direkt anbinden, werden nicht immer als offizielle Actions angeboten.
  • Beispiel: eine Action, die einen Pull Request programmatisch zur Merge Queue hinzufügt
  • Im GitHub CLI gibt es gh pr merge, aber nicht als exponierte Action

• Beispiele eingestellter offizieller Actions

  • actions/create-release: seit März 2021 nicht mehr gepflegt
  • Nutzern wurde empfohlen, auf community-gepflegte Workflows umzusteigen.
  • Als repräsentatives Beispiel wurde softprops/action-gh-release genannt.
  • actions/upload-release-asset: im selben Zeitraum wie actions/create-release als nicht mehr gepflegt markiert
  • actions/setup-ruby: seit Februar 2021 nicht mehr gepflegt
  • Nutzern wurde empfohlen, zu ruby/setup-ruby zu wechseln.
  • Der Wechsel selbst war relativ schmerzarm, aber der Eindruck, dass zentrale Bausteine aufgegeben werden können, schadet dem Vertrauen in die Plattform.
  • Wenn es an offiziellen hochwertigen Actions fehlt, greifen Nutzer direkt auf die GitHub-API-Oberfläche zu und machen dabei weiterhin Sicherheitsfehler.

• Verbesserungsrichtung für das Ökosystem

  • Aufgaben, die unterschiedliche Teile der GitHub-Infrastruktur direkt verbinden und derzeit manuell per REST-API-Aufruf oder gh-Ausführung erledigt werden müssen, wären als offizielle Actions wertvoll.
  • In Zusammenarbeit mit großen Third-Party-Actions könnte eine quasi-offizielle Organisation wie community-actions entstehen.
    • Von GitHub geprüfte Actions
    • Einhaltung von Best Practices für Repository-Sicherheit
    • Semantic-Version-Updates
    • Ein klarer Vertrauenspfad für wichtige Actions des Ökosystems

Bestehende Tools und GitHubs Roadmap

• Viele empfehlen das lokale GitHub-Actions-Emulationstool nektos/act.
  • Es ist nützlich, um einfache Workflows schnell zu iterieren und zu debuggen.
  • Da Images und Events aber nicht immer vollständig der echten GitHub-Umgebung entsprechen, wird es als verlustbehaftetes Werkzeug eingeschätzt.
• rhysd/actionlint wird für lokales Linting und Security-Linting verwendet.
  • Eine Einschränkung ist, dass nur Workflows, nicht aber Actions gelintet werden können.
• Die GitHub Actions extension for VS Code bietet Linting im Editor und Integration mit Repository-Workflows.
  • Sie basiert auf dem öffentlichen JSON-Schema.
  • Sie zeigt laufende Workflows an und bietet Variablenvervollständigung.
  • Probleme wie Tippfehler bei Secrets oder Tippfehler in dynamisch erzeugten Output-Namen erkennt sie jedoch nicht, weshalb Debugging per add-commit-push weiterhin nötig bleibt.
• Julian Dunn, verantwortlich für das Produktmanagement des GitHub-Actions-Projekts, teilte einige laufende Funktionen und Prioritäten mit.
  • Interaktives Debugging steht auf der öffentlichen Roadmap von GitHub Actions.
  • Auch die Arbeit an einem unveränderlicheren Ansatz statt Workflow-Pinning per Tag oder SHA steht auf der öffentlichen Roadmap.
  • GitHub betrachtet die Gesundheit und Qualität des offiziellen Action-Ökosystems als Priorität und verfolgt die Strategie, die Zahl offizieller Actions klein zu halten, damit jede einzelne ausreichend Pflege und Aufmerksamkeit erhält.

[GN⁺]

Meinungen auf Hacker News

• Es gibt zwei Arten, GitHub-Actions-Workflows zu nutzen. 1) Man „programmiert“ mit GitHub Actions, hängt für Dinge wie E-Mail-Versand Marketplace-Tools an, die YAML wächst auf 500–1000 Zeilen an, ist voller Bedingungen und wird schwer verständlich.
  2) Man nutzt GitHub Actions nur zur „Konfiguration“ und fragt sich ständig: „Kann ich diese YAML-Komplexität in ein Skript auslagern?“ Packt man auch den E-Mail-Versand in ein Skript, ist der Workflow mit etwa 50–60 Zeilen erledigt, und man kann das Skript lokal debuggen, wodurch die dumme push-debug-commit-Schleife fast verschwindet. Jedes Mal, wenn ich in ein neues Team komme, sage ich, dass 1 der Weg in den Wahnsinn ist und 2 vernünftig ist, aber etwa die Hälfte entscheidet sich trotzdem für 1. Mangel an Debugging-Tools und Vendor-Lock-in sind ebenfalls deutlich weniger problematisch, wenn man 2 wählt.

  • Dieser Sichtweise stimme ich weitgehend zu. Wenn man nicht versucht, GitHub Actions in YAML zu programmieren, sondern es nur als Basis zur Ausführung von Tasks behandelt, verschwinden viele Schmerzen.
    Allerdings reicht es oft nicht, einfach alles in eine richtige Programmiersprache auszulagern. Manchmal muss man anbieterspezifische Funktionen von GHA nutzen, Abhängigkeiten zwischen Jobs ausdrücken oder eine REST-API aufrufen, die bereits gut als Action abstrahiert ist. Man kann das in der Sprache der Wahl neu implementieren, aber dadurch verschwindet die Anbieterabhängigkeit nicht und es bleibt fragil. Letztlich ist das Vendor-Lock-in-Wertversprechen von GHA sehr stark; um Leute von Variante 2 zu überzeugen, braucht es also stärkere Vorteile.
  • Variante 2 macht es Entwicklern auch leichter, Builds lokal auszuführen. Man nutzt dieselbe Build-Chain für lokales Debugging sowie Test-, Staging- und Produktionsumgebungen und muss keine unterschiedlichen Build-Abläufe pflegen.
    Das gilt nicht nur für GHA, sondern für alle Build-Server. Ein Build-Server sollte ein Skriptausführer sein, der Historie, Artefaktverwaltung sowie Berechtigungen/Audits hinzufügt; der eigentliche Build-Prozess sollte an das Repository delegiert werden, das gebaut wird.
  • Gute Sichtweise. Wenn man GitHub selbst automatisieren will, etwa Aufgaben wie Rollenzuweisungen oder Tagging, ist Variante 1 allerdings schwer zu vermeiden. Trotzdem würde ich derzeit lieber einen beträchtlichen Teil manuell erledigen, als die furchtbare Debug-Schleife von GHA zu durchlaufen.
    Zur Info: Es gibt nektos/act, um das Verhalten von GHA lokal nachzubilden: https://github.com/nektos/act
  • Ich frage mich, wie man Actions debuggt. Es ist absurd, so viel Zeit in der commit-action-debug-change-Schleife zu verbringen. Ich stimme völlig zu, dass Variante 2 das Debuggen von Skripten viel einfacher macht. CI sollte lokal ausführbar sein, aber GitHub Actions lässt sich trotz einiger Tools nicht besonders leicht so nutzen.
  • Der Hauptgrund, Variante 2 anzustreben, ist, dass man Builds lokal ausführen kann, selbst wenn GitHub ausfällt, und sie bei Bedarf leicht woandershin umziehen möchte.
    Build/Test/Signierung/Deployment usw. sollten möglichst portabel als Skripte geschrieben sein, und diese Skripte müssen immer lokal funktionieren. GitHub sehe ich nur als etwas, das automatisch eine Umgebung zum Ausführen dieser Skripte vorbereitet und sie tatsächlich startet.

• Die Schleife aus git commit, push, wait ist eine furchtbare User Experience. Nutzer haben portable Pipelines verdient, die überall laufen, auch auf der lokalen Maschine. Act löst dieses Problem bis zu einem gewissen Grad, bildet die echte Umgebung aber meist nicht wirklich ab.
  Viele Pipelines lassen sich nicht lokal wie in Produktion ausführen, aber in weniger kritischen Entwicklungsphasen gibt es keinen Grund, solche Workflows nicht zu erfassen und lokal auszuführen. Garden bietet portable Pipelines und ergänzt Caching über den gesamten Abhängigkeitsgraphen hinweg. Bei einigen Kunden sank die Laufzeit um mehr als 80 %, und Entwickler sehen sofort, ob Tests bestehen oder fehlschlagen, ohne zuerst auf git pushen zu müssen. Es ist Open Source: https://github.com/nektos/act, https://docs.garden.io

  • Wenn Leute keine bash-Skripte in Actions hineingestopft hätten, sondern Actions nur make oder bash-Skripte aufrufen ließen, gäbe es dieses Problem nicht. CI/CD und Entwickler sollten alle dieselben Targets/Befehle wie make release verwenden.
  • Das Prinzip „CI sollte keine besondere Schneeflocke sein“ scheint stark verloren gegangen zu sein, als man begann, eigene Teams für DevOps und DevOps-Tools aufzubauen. In dem Moment, in dem etwas zu einem Beruf wird, scheint der Kipppunkt erreicht zu sein, an dem es übermäßig kompliziert wird. Dasselbe Phänomen sieht man bei Agile mit großem A und Scrum Mastern, die ihre Zeit füllen müssen.
  • Wegen der Unvollkommenheiten von Act habe ich schon mehrfach an völlig falschen Stellen gesucht. Im Moment bin ich erst einmal zur alten Schleife zurückgekehrt und hoffe, dass es mit der Zeit besser wird.
  • Build-Pipelines brauchen auch so etwas wie Terraform. Wenn man Bitbucket nutzt, möge Gott einem helfen.
  • Die Landingpage von garden.io wirkt auf iOS kaputt. Sie läuft rechts aus dem Bildschirm heraus.

• Ich kann den Schmerz beim Debuggen von GH-Actions-Läufen absolut nachvollziehen. Das einzige Werkzeug, das man hat, ist Debugging einzuschalten und den Lauf erneut zu starten. Es gibt viel zu viele Müll-Commits, die nur dazu dienen, eine Pipeline zu reparieren oder zu debuggen, und meistens läuft es darauf hinaus, einfach irgendetwas auszuprobieren, um zu sehen, ob es funktioniert.
  Selbst sehr grundlegende Dinge wie wiederverwendbare Logik sind unnötig kompliziert oder schlecht dokumentiert. Wenn man es einmal weiß, ist es ziemlich einfach, aber die GitHub-Dokumentation war miserabel. Es sah so aus, als müsse man eine Action veröffentlichen oder in ein anderes Repository legen, um Wiederverwendbarkeit zu bekommen, tatsächlich kann man aber einfach eine neue YAML-Datei mit wiederverwendbarer Logik erstellen. Sie muss nur im Root des workflows-Ordners liegen, damit es funktioniert. Mit GH Actions zu arbeiten ist wirklich schmerzhaft, aber sobald es läuft, ist es sehr bequem. Es wäre schön, so etwas wie einen lokalen Runner zu haben, um Actions zu testen, bevor man committet und pusht.

  • Eine Möglichkeit dafür sind Draft-PRs. In einem Draft-PR kann man Änderungen an Action-YAML ausführen, und wenn man zufrieden ist, kann man im eigentlichen PR zum Mergen die Commits passend squashen und es sauber übernehmen. Zum Debuggen oder Entwickeln von GH-Action-Logik waren Draft-PRs ziemlich brauchbar.
  • Es kann nicht alles, aber es gibt ein recht nützliches Tool: https://github.com/nektos/act
  • Wenn ich CI repariere, mache ich das immer auf einem Feature-Branch und am Ende per Squash-Merge. Schnelle Fixes, die in einem Rutsch erledigt sind, gibt es fast nie; es werden immer 3 bis 10 Commits.
  • Ich habe schon einmal versucht, das GitHub-Runner-Image oder ein nachgebautes Image auszuführen, aber die Einrichtung und das Verhalten einiger Funktionen waren derart schmerzhaft, dass ich nach zwei Tagen aufgegeben habe.
    Das ist auch nicht nur ein GitHub-Problem. Andere große CI-Plattformen sind bei Workflows und Integrationen auch nicht wirklich besser. Inzwischen skripte ich möglichst alles.
  • Das ist einer der Hauptgründe, warum wir Earthly gebaut haben: Builds lokal ausführen zu können und Konsistenz mit CI zu bekommen.

• GitHub Actions ist ein miserables CI/CD-System. Man kann Schritte nicht parallel auf derselben VM ausführen, und containerbasierte Jobs werden wie Bürger zweiter Klasse behandelt.
  Wegen des ersten Problems kann man das Einrichten lokaler Credentials oder umgebungsabhängiger Konfiguration nicht parallelisieren. Wenn ich sehe, dass google-github-actions/setup-gcloud über eine Minute braucht, macht mich das wütend. Wegen des zweiten Problems ist es sehr schwierig, die CI-Umgebung über ein Dockerfile im Repository zu beschreiben, bei Änderungen am Image-Inhalt das CI-System das Image neu bauen und davon abhängige Workflows warten zu lassen, und bei unverändertem Inhalt ohne Rebuild sofort mit bereits installierten Abhängigkeiten zu starten. Bei GitHub Actions landet man immer wieder dabei, den Cache neu befüllen zu wollen. Der Cache hat ein Limit von 5 GB, lässt sich auch gegen Geld nicht erhöhen und wird per FIFO verdrängt; wenn man über 5 GB kommt, ist er praktisch so gut wie nicht vorhanden. Ich vermisse Concourse wirklich. Dort waren parallele Jobs, benutzerdefinierte Pipeline-Trigger, SSH in die CI-Umgebung zum Debuggen, einmalige Jobs ohne Pipeline und das Weitergeben von Verzeichnisinhalten zwischen Jobs ohne Erzeugen von Artefakten möglich. GitHub Actions ist eher ein Spielzeug-CI/CD, das vor allem wegen des niedrigen Einstiegs beliebt wurde: eine Datei nach .github/workflows legen und loslegen. Gut, um Leute an Bord zu holen, aber jenseits der Anfangsfunktionen nicht mächtig genug, um es „das Beste“ zu nennen.

  • Wegen des 5-GB-Cache-Limits kann ich jetzt wohl endlich untersuchen, warum „Build-Caching seltsam kaputtgeht“. Danke für den Hinweis.
  • Concourse ist großartig. Ich wusste nicht, dass das Team aufgelöst wurde; das ist wirklich schade. Auch Zitos Kommunikationsstil war erstklassig.
  • Ich würde eher sagen, dass es nach der Übernahme von VMWare aufgelöst wurde, nicht von Pivotal. Intern gab es viele Leute, die Concourse mochten. Ich bin allerdings vor der Übernahme gegangen.
    SSH-Debugging und einmalige Jobs waren wirklich ein Traum.
  • Hast du dir Tekton angesehen? https://tekton.dev/
  • Es gibt eine bestehende Lösung, die viele dieser Probleme berücksichtigt. Ich würde gern ein paar Meinungen dazu hören. Es wäre schön, wenn du deine E-Mail-Adresse teilst oder dich unter [e-mail] meldest.

• Ich verstehe nicht, wie es noch immer nicht behoben sein kann, dass GitHub nicht zwischen SHA-Referenzen aus Forks und Nicht-Forks unterscheiden kann und ein Fork dadurch die Sicherheitseinstellungen von GitHub Actions umgehen kann.
  Wenn sich Sicherheitskontrollen leicht umgehen lassen, ist das ein schwerwiegendes Sicherheitsproblem. Man muss zwar jemanden dazu bringen, die eigene SHA zu verwenden, aber Social Engineering ist normalerweise der einfache Teil.

• Ehrlich gesagt ist es peinlich, wie schlecht das ist. Es ist auch seltsam, dass Benachrichtigungen über unabhängige Build-Fehlschläge zufällig nur an den neuesten Maintainer gehen, der zuletzt gemergt hat. Es kann passieren, dass ich eine Woche lang nicht merke, dass mein Update/Build fehlschlägt, bis mich ein neu hinzugekommener Maintainer über Matrix darauf hinweist.
  Die Cache-Action ist schon mit bloßem Auge offensichtlich kaputt, aber es scheint niemanden zu geben, der sie betreut. Wenn die UI kaputtgeht oder der Tab entladen wird, kann man nicht einmal mehr die Build-Logs eines Schritts tailen. Es gibt praktisch keine Abstraktionen, um Workflows zwischen Worker-Nodes portabel zu machen. Die Basis-Images sind nahezu eine Katastrophe. Anfangs fand ich sie nur ärgerlich aufgebläht, aber je tiefer ich grub, desto mehr dachte ich: „Das hat wohl jemand bei Microsoft übernommen, der Linux nicht kennt.“ Es gibt keinerlei Bemühungen, leichtere Images für Leute bereitzustellen, die Nix oder Docker verwenden. Ich bin gerade dabei, mich von GitHub zu lösen, und der Hauptgrund ist, dass Actions mir die Augen geöffnet hat. Der Grund, warum ich nicht in YAML programmiere, ist, dass ich YAML für eine Schande halte, entstanden durch VC-Geld, das in ein Ökosystem geflossen ist, das keine modernen, tatsächlich nützlichen Technologien kennt.

  • War es nicht offensichtlich, dass so etwas passieren würde, als Microsoft GitHub übernommen hat?

• Ich kann https://pre-commit.ci sehr empfehlen. Ich bin nicht daran beteiligt, nur ein zufriedener Nutzer.
  Die Idee ist, Hooks zu schreiben oder bestehende Hooks zu verwenden, die den Code vor dem Commit prüfen und wenn möglich korrigieren; nach dem Push prüft die CI erneut und erstellt bei Bedarf sogar automatisch einen Korrektur-Commit. Dank gutem automatischem Caching ist es fast unglaublich schnell, und weil auf der lokalen Entwicklungsmaschine und in der CI dieselbe Konfiguration verwendet wird, gibt es deutlich weniger Debugging-Probleme. Für Open Source ist es kostenlos. Automatische Releases oder Ähnliches macht es nicht, es prüft nur – aber das macht es sehr gut.

  • Bei Python-Projekten ist es besonders gut, das zusammen mit tox zu verwenden. tox erstellt passend zur zu testenden Python-Version ein virtualenv und führt die Tests darin aus.
    Wenn man den Quellcode selbst prüfen will, kann man mit skip_install = True auch statische Prüfungen laufen lassen. Man führt es einfach in einem Container aus, in dem tox als globales Tool installiert ist und alle benötigten Python-Versionen vorhanden sind. Ein Beispiel wäre ein Image wie https://github.com/georgek/docker-python-multiversion. Es wird nicht gepflegt, ist aber leicht zu aktualisieren. Etwas Boilerplate wie [tox] envlist = py{310,311}, [testenv] und [testenv:check] mit pre-commit run --all-files --show-diff-on-failure reicht aus.

• Nachdem ich zu oft in der Schleife git commit; git push; repeat festhing, habe ich https://github.com/mxschmitt/action-tmate entdeckt. Es öffnet zwischen den Schritten einen Shell-Zugriff; das löst nicht alle Probleme, reduziert den Schmerz aber manchmal deutlich.

• Persönlich fände ich es gut, wenn man einem Action-Run HTML-Reports anhängen könnte, ohne derzeit Dinge wie actions/upload-artifact verwenden zu müssen.
  Besonders bei Test-Builds möchte man die ausgegebenen HTML-Reports oft schnell ansehen. Die mir bekannten Wege sind derzeit upload-artifact oder GH Pages, aber GH Pages ist nicht ideal, wenn es im selben Repository mehrere Report-Ausgaben gibt oder wenn man schnell einen älteren statt des neuesten Reports sehen möchte. Es wäre schön, eine einfache attach-report-Action zu haben, die in der Job-Zusammenfassung einen Link zum HTML-Report anfügt und beim Anklicken das HTML rendert. Andere automatisierte CI/CD-Systeme bieten das Erfassen und Anzeigen von HTML-Reports standardmäßig deutlich umfangreicher an.

  • Es ist zwar kein HTML, aber man kann Markdown-Ausgaben direkt zu $GITHUB_STEP_SUMMARY hinzufügen, ohne Artefakte hochzuladen oder Ähnliches.

• Meiner Ansicht nach ist GH Actions im Grunde eher ein Rebranding von Microsofts „Azure Pipelines“. Aus der Perspektive von jemandem, der alle früheren Formen von TFS-/VSTS-/AzDO-Build- und Release-Pipelines genutzt hat: Dieses Team ist darin nicht gut.
  Azure Pipelines wurde überhaupt erst einigermaßen brauchbar, weil buchstäblich jeder vorherige Ansatz gescheitert war. Es gab auch ein Projekt, Pipelines lokal auszuführen, damit man ohne Commit in der eigenen Umgebung eine edit-run-debug-Schleife durchlaufen kann, aber das wurde natürlich eingestellt: https://github.com/microsoft/azure-pipelines-agent/pull/2687/files#diff-570b52bcb927a5365c22d17a21e8e19e1ba3427c7f3ec16ea64b7b3d14e4ee20. Trotzdem gibt es Tools, die die Lebensqualität verbessern. Zum Beispiel eine VS-Code-Erweiterung mit Syntax-Unterstützung: https://marketplace.visualstudio.com/items?itemName=ms-azure-devops.azure-pipelines. Etwas kontrovers formuliert: Hätte man XML statt YAML verwendet, hätte man allein mit einer xmlns-Deklaration am Anfang in den meisten brauchbaren Code-Editoren ohne weiteres Zutun Validierung bekommen. XML ist furchtbar, aber es gab auch viele nützliche Funktionen, die wir mit dem kompletten Wegwerfen gleich mitverloren haben.

  • Ich hatte verstanden, dass GHA schon vor der Übernahme durch Microsoft ein intern bei GitHub unabhängig ziemlich weit fortgeschrittenes Projekt war. Ich frage mich, ob damit gemeint ist, dass GHA auf AzP neu aufgebaut wurde, dass AzP einfach nur einen neuen Namen bekommen hat, oder etwas anderes.
  • Das ist wahrscheinlicher, als die meisten denken. Nach der Übernahme wechselte ein erheblicher Teil des AzDo-Teams zur Arbeit an GitHub Actions/Projects.
  • Bis zum letzten Absatz war ich einverstanden. XML tut den Augen weh. Statt des Schreckens aus spitzen Klammern und camelCase nehme ich lieber ein hübsch formatiertes YAML-Dokument, auch wenn es schmerzhaft ist.