In GitHub Actions kann jedes beliebige Programm als Shell verwendet werden

• In GitHub Actions lässt sich die zum Ausführen eines run:-Blocks verwendete Shell mit dem Schlüsselwort shell festlegen
• In Workflows ist das optional, in einzelnen Action-Definitionen jedoch erforderlich
• Der Standardwert wird je nach Betriebssystem automatisch gesetzt: unter Linux/macOS bash, unter Windows pwsh
• Wenn man explizit shell: bash setzt, werden auch die folgenden Standard-Flags hinzugefügt: --noprofile --norc -eo pipefail

Jedes ausführbare Programm kann als shell angegeben werden

• Man geht leicht davon aus, dass die für shell nutzbaren Werte eingeschränkt sind
• Tatsächlich kann jede ausführbare Datei in $PATH als Shell verwendet werden
• Wenn der auszuführende Befehl keine Dateieingabe annimmt, muss das spezielle Argument {0} übergeben werden
• {0} wird von GitHub automatisch durch den Pfad einer temporären Datei ersetzt

Experimentelle Beispiele

• Es ist sogar möglich, einen C-Compiler (tcc) wie eine Shell zu verwenden und direkt auszuführen
• Ebenso kann man durch Manipulation von $PATH eine gefälschte bash-Shell erstellen und verwenden
• GitHub kümmert sich nicht darum, welche ausführbare Datei tatsächlich im shell-Eintrag angegeben ist

Sicherheitstechnische Implikationen

• In GitHub Actions ist die Grenze zwischen Dateischreiben und Ausführen unscharf (auch über GITHUB_ENV, $GITHUB_PATH usw. besteht Ausführungspotenzial)
• Selbst bekannte Werte wie shell: bash werden über $PATH aufgelöst und nicht über einen festen Ausführungspfad wie /bin/bash
• Anders als erwartet werden auch Werte wie python wirklich pfadbasiert ausgeführt und nicht nur als Verweis auf einen Tool-Cache

[tujuc]

Schon ein Blick in das Repository github/runner-image zeigt, dass dort ziemlich viele Pakete vorinstalliert sind, die man direkt nutzen kann....

Wenn man ein Image baut, sind 1 GB ganz schnell erreicht....

[GN⁺]

Hacker-News-Kommentare

• Ich habe in der Vergangenheit die -x-Option von bash verwendet, um die Ausgabe aller Befehle zu erzwingen, die in einem Actions-Workflow ausgeführt werden. Das ist für das Debugging sehr nützlich.
• Ein cooler inoffizieller Trick in GitHub Actions, den ich bei der Arbeit entdeckt habe, ist das Abgleichen von repository_dispatch-Ereignisnamen mit Wildcards.
  • Das ist die einzige Möglichkeit, wiederverwendbare Workflows durchzusetzen, die über eine zentralisierte Release-Pipeline definiert sind.
  • Beim Dispatchen eines Ereignisses lassen sich Produkt und Version leicht identifizieren.
• Meiner Erfahrung nach gilt: Je weniger man in GitHub Actions erledigt, desto besser.
  • Ich bevorzuge es, Logik in einem Build-System zu kodieren, etwa in Make, und sie von GitHub Actions aus aufzurufen,
  • oder ein kleines CLI-Programm zu schreiben und es von GitHub Actions aus aufzurufen.
  • Lokal zu debuggen ist viel einfacher, als in CI zu debuggen.
• Es gab eine Generation, die Angst hatte, als man sie bat, Tabellenkalkulationen in Code umzuwandeln.
  • Diese Generation wird Angst haben, wenn man sie bittet, Deployments, die mit GitHub Actions gebaut wurden, zu disziplinieren.
• Der Code des GitHub Actions Runner lässt sich gut lesen.
  • Es gibt eine bestimmte Stelle, an der Standardargumente für populäre Shells/Binärdateien definiert sind.
  • In ScriptHandler.cs befindet sich der gesamte Code, der Prozessumgebung, Argumente usw. vorbereitet.
  • Insgesamt war ich positiv überrascht von der Schlichtheit dieses Codes.
• Man kann die Standard-Shell bash so austricksen, dass praktisch jedes Programm ausgeführt werden kann.
  • Solange Leute, die andere Actions lesen, verstehen, was dort passiert, ist das sehr nützlich.
  • Ich habe erlebt, wie Shell-Skripte mit ein paar Zeilen beginnen und dann zu Monstern mit weit über hundert Zeilen anwachsen.
  • Ich wollte Funktionen wie Arrays und Typen aus der Python-Standardbibliothek.
• Das gibt mir Hoffnung, Go-Code, der CI-Jobs direkt aus GitHub-Workflow-YAML-Dateien ausführt, einfach laufen lassen zu können.
  • goeval unterstützt derzeit noch keine Dateieingaben direkt.
  • Dafür braucht es einen Shell-Trick.
  • Ein wenig Boilerplate ist nötig.
  • Ich bin der Autor von goeval.
• Ich frage mich, worin genau der Vorteil von GitHub-CI-YAML liegt.
• In CI/CD kann man jetzt C schreiben und es Low-Level-Systemarbeit nennen.
  • Vermutlich könnte man auch Assembler schreiben.