GitHub Actions

Hallo, hier ist Alex von DEV STORIES DOT EU. GitHub Actions, Folge 1 von 14. Die meisten Enterprise-Builds werden als reiner Nachgedanke in einem komplett separaten Tool behandelt. Du pushst Code, ein Context Switch findet statt, und du hoffst, dass ein Webhook auf einem Remote-Server irgendwo anders korrekt feuert. Der Enterprise Case für GitHub Actions schließt diese Lücke, indem er deine Pipeline Execution direkt neben deinen Source Code verlegt. Ein weit verbreitetes Missverständnis ist, GitHub Actions ausschließlich als CI/CD-Tool zu betrachten, als wäre es lediglich ein moderner Ersatz für Jenkins. Nenn es lieber das, was es wirklich ist: Es ist eine flexible, Event-driven Automation Engine, die tief in dein Repository eingebettet ist. Sie reagiert auf praktisch jede State Change innerhalb der Version Control Plattform. Schau dir ein Standard-Enterprise-Setup mit Tools wie GCP Cloud Build oder Azure DevOps an. Der Source Code lebt in GitHub, aber die Execution passiert woanders. Das erfordert das Managen von Cross-Platform Service Accounts, die Wartung fragiler Webhooks und die Synchronisierung von Access Controls über mehrere Anbieter hinweg. Wenn eine Pipeline fehlschlägt, verlassen Entwickler ihr Repository, loggen sich in eine separate Cloud Console ein und wühlen sich durch Logs, die komplett von ihrem Pull Request entkoppelt sind. Die Nähe zum Code beseitigt diese Reibung. Wenn deine Automation Engine direkt in die Version Control Plattform eingebaut ist, eliminierst du die Integration Tax. Die User Identity, die Branch Protection Rules und der Kontext der Code-Änderung werden von der Compute-Instanz, die deine Pipeline ausführt, nativ verstanden. Stell dir eine traditionelle Pipeline in einem separaten Cloud Build Tool vor. Sie lauscht typischerweise auf einen Code Commit, zieht den Source Code runter, baut ein Artifact und meldet einen simplen Pass- oder Fail-Status an das Repository zurück. Ihre gesamte Weltsicht beschränkt sich auf Code Compilation und Deployment. Eine GitHub Action operiert auf einer viel breiteren Ebene. Weil sie Repository Events nativ versteht, kannst du einen Workflow bauen, der exakt in dem Moment triggert, in dem ein Pull Request geöffnet wird. In einem einzigen, nahtlosen Run kann sie die Event Payload lesen, die richtigen Senior Engineers als Reviewer zuweisen, basierend darauf, welche spezifischen Files geändert wurden, einen Linter ausführen und jegliche Syntax-Fehler direkt als Inline Comments an den exakten Codezeilen posten. Der Entwickler löst die Issues, ohne jemals die Pull Request View zu verlassen. Du automatisierst den Workflow selbst, nicht nur das Build Artifact. Aus architektonischer Sicht verwandelt das dein Repository von einem passiven Storage Volume in einen aktiven Controller. Du hörst auf, nur deine Deployments zu automatisieren, und fängst an, deine Operational Governance zu automatisieren. Wenn ein Issue mit einem Critical Label getaggt wird, kann eine Action automatisch eine temporäre Testing Database provisionieren. Wenn eine Security Vulnerability durch einen automatisierten Dependency Scan geflaggt wird, kann eine Action sofort ein Tracking Ticket öffnen, das Security-Team zuweisen und dein internes Chat-System anpingen. Alles nutzt exakt dieselbe zugrundeliegende Compute Infrastructure. In einer großen Organisation kannst du diese Workflows zentral definieren und sie über Hunderte von Repositories hinweg teilen. Wenn dein Security-Team die erforderliche Container Scanning Policy updatet, aktualisieren sie eine einzige zentrale Action. Jedes Repository, das diese Action aufruft, erbt sofort die neue Security Requirement, ohne dass einzelne Produkt-Teams ihre Pipeline Scripts neu schreiben müssen. Diese Zentralisierung bietet massiven Leverage für Platform Engineering Teams. Hier ist die entscheidende Erkenntnis. Enterprise Architecture kämpft ständig mit Tool Sprawl. Jedes neue Pipeline Tool erhöht den Cognitive Load, erfordert dedizierte Maintenance und schafft eine weitere Surface Area für Security Policies. Indem du deinen Execution Layer direkt in GitHub konsolidierst, standardisierst du das Verhalten jedes Repositories. Exakt dieselbe Infrastruktur, die deine Production Microservices deployt, managt auch deine Repository Maintenance. Der ultimative architektonische Vorteil von GitHub Actions ist nicht, dass es schnellere Build Agents oder besseres Caching hat. Er liegt darin, dass es die Grenze zwischen dem Developer Workflow und dem Continuous Integration System aufhebt. Wenn du diese Episoden nützlich findest und die Show unterstützen möchtest, kannst du auf Patreon nach DevStoriesEU suchen. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. GitHub Actions, Folge 2 von 14. Ein Workflow ist nicht einfach nur ein simples Skript, das von oben nach unten durchläuft. Er ist eine parallelisierte State Machine, die deinen Code zur exakt gleichen Zeit auf mehrere virtuelle Maschinen verteilt. Wenn du deine Config so schreibst, dass du einen einzigen durchgehenden Prozess erwartest, verschwinden deine Daten auf halber Strecke. Wenn du das Mental Model der Execution verstehst, verhinderst du genau das. Auf der obersten Ebene steht der Workflow. Das ist ein konfigurierbarer, automatisierter Prozess, der in einer YAML-Datei in deinem Repository definiert wird. Er enthält die Blaupause dafür, was passieren soll, wenn er getriggert wird. Ein Workflow selbst führt Code nicht direkt aus. Er orchestriert die Ebene darunter. Ein Workflow enthält einen oder mehrere Jobs. Hier werden die physischen Execution-Grenzen gesetzt. Standardmäßig läuft jeder Job in einem Workflow parallel. Wenn du einen Build-Job und einen Test-Job definierst, fährt GitHub für jeden Job eine separate virtuelle Maschine hoch, einen sogenannten Runner. Sie starten zur exakt gleichen Zeit. Sie wissen absolut nichts voneinander. Der Build-Job läuft auf Runner A und der Test-Job läuft auf Runner B. Weil sie auf komplett unterschiedlichen virtuellen Maschinen ausgeführt werden, teilen sie sich weder das Filesystem noch Environment Variables oder den Memory. Innerhalb eines Jobs ändert sich das Execution-Modell komplett. Ein Job besteht aus einer Sequenz von Steps. Während Jobs parallel auf verschiedenen Maschinen laufen, werden Steps sequenziell auf exakt derselben Maschine ausgeführt. Step eins ist fertig, bevor Step zwei beginnt. Weil sie auf demselben Runner laufen, teilen sich die Steps ihre Daten. In unserem Build-Job lädt Step eins vielleicht deinen Application-Code herunter. Step zwei kompiliert ihn. Step drei verpackt ihn. Weil diese Steps auf derselben virtuellen Maschine passieren, liest Step zwei ganz nativ die Files, die von Step eins heruntergeladen wurden. Das bringt uns zu einem häufigen Missverständnis. Leute verwechseln oft Steps und Actions. Ein Step ist keine Action. Ein Step ist einfach nur eine Execution-Einheit innerhalb eines Jobs. Er ist ein Slot in deiner Sequenz. Du kannst diesen Slot auf zwei Arten füllen. Du kannst einen direkten Shell-Command schreiben, oder du rufst eine Action auf. Eine Action ist ein gepackter, wiederverwendbarer Codeblock, der dafür gemacht ist, einen bestimmten komplexen Task auszuführen, wie zum Beispiel das Setup eines Language Environments. Eine Action ist der wiederverwendbare Payload. Der Step ist der Container, der sie innerhalb der Job-Sequenz hält. Schauen wir uns unser Build- und Test-Szenario noch einmal an. Der Workflow startet. Zwei Runner booten gleichzeitig. Auf dem Build-Runner werden die Steps nacheinander ausgeführt. Der erste Step ruft eine Checkout-Action auf, um das Repository zu fetchen. Der zweite Step führt einen Shell-Command aus, um den Code zu kompilieren. Diese Steps teilen sich den lokalen Disk-Space nahtlos. Währenddessen läuft auf dem Test-Runner eine komplett andere Sequenz von Steps völlig isoliert ab. Wenn dein Test-Job den kompilierten Output vom Build-Job braucht, kann er nicht einfach auf der Festplatte nachschauen. Der Test-Job ist auf einem anderen Server. Hier ist die wichtigste Erkenntnis. Die Grenze eines Jobs ist die physische Grenze der virtuellen Maschine. Das bedeutet, dass das Schreiben eines GitHub Actions Workflows eigentlich eine Infrastructure Mapping Exercise ist. Danke fürs Dabeisein. Ich hoffe, du hast etwas Neues mitgenommen.

Hallo, hier ist Alex von DEV STORIES DOT EU. GitHub Actions, Folge 3 von 14. Ein einzelner automatisierter Commit wird in dein Repository gepusht. Dieser Commit triggert einen Workflow. Dieser Workflow macht einen weiteren Commit, der den Workflow erneut triggert. Innerhalb weniger Minuten hast du so versehentlich hunderte von Run Minutes in einer Infinite Loop verbraten. Um das zu verhindern und genau zu steuern, wann deine Workflows ausgeführt werden, nutzt du Event-Driven Triggers und Filter. Jeder GitHub Actions Workflow beginnt mit dem on Keyword. Das teilt GitHub mit, welche Events deinen Workflow aufwecken sollen. Du kannst ein einzelnes Event, wie zum Beispiel einen Push, oder mehrere Events in einem Array angeben. Aber Events sind nicht immer einfache Trigger. Einige Events, wie Issues oder Pull Requests, haben mehrere Activity Types. Wenn ein Issue geöffnet, bearbeitet oder geschlossen wird, feuert es dasselbe Base Event. Wenn du einfach nur schreibst, dass ein Workflow bei Issues läuft, wird er für all diese Aktivitäten ausgeführt. Um präzise zu sein, gibst du die genauen Activity Types an. Du kannst GitHub sagen, dass der Workflow nur laufen soll, wenn ein Issue geöffnet wird, und Bearbeitungen oder Schließungen ignoriert werden. Das spart Run Minutes und verhindert unnötige Verarbeitung. Activity Types kümmern sich darum, was passiert ist, aber Branch und Path Filter kümmern sich darum, wo es passiert ist. Wenn du einen Workflow bei einem Push oder Pull Request triggerst, willst du normalerweise nicht, dass er auf jedem einzelnen Branch läuft. Du nutzt Branch Filter, um bestimmte Ziele anzusteuern, wie den Main Branch oder Release Branches. Du kannst auch nach Paths filtern. Wenn ein Entwickler einen Tippfehler in einer Readme Datei fixt, musst du nicht deine gesamte Test Suite laufen lassen. Path Filter erlauben es dir, bestimmte Dateien und Verzeichnisse ein- oder auszuschließen. Hier ist der entscheidende Punkt. Wenn du positive und negative Path Filter mischst, ist die Reihenfolge wichtig, in der du sie schreibst. Ein positiver Filter sagt dem Workflow, dass er laufen soll, wenn sich ein bestimmter Path ändert. Ein negativer Filter, gekennzeichnet durch ein Ausrufezeichen, sagt dem Workflow, dass er Änderungen in einem Path ignorieren soll. GitHub wertet diese von oben nach unten aus. Wenn du einen negativen Filter nach einem positiven Filter setzt, überschreibt der negative Filter den positiven für alle passenden Dateien. Lass uns das in die Praxis umsetzen. Du willst einen Build triggern, sobald Code in den Main Branch gepusht wird, aber du willst Geld sparen, indem du Änderungen ignorierst, die nur die Dokumentation betreffen. Unter dem on Keyword gibst du das Push Event an. Darunter definierst du einen Branch Filter für main. Dann fügst du einen Paths Filter hinzu. Du könntest mit einem positiven Filter für alles beginnen und eine Wildcard nutzen. Direkt darunter fügst du einen negativen Filter für den docs Ordner hinzu, der speziell auf Markdown Dateien abzielt. Wenn ein Commit nur eine Markdown Datei im docs Ordner ändert, bleibt der Workflow inaktiv. Wenn ein Commit eine Python Datei und eine Markdown Datei ändert, läuft der Workflow, weil die Python Datei den positiven Filter triggert. Nun zurück zu dieser Infinite Loop. Wenn dein Workflow läuft, stellt GitHub ein temporäres Credential namens GitHub Token bereit, um sich gegenüber dem Repository zu authentifizieren. By Design erzeugen Events, die mit diesem spezifischen Token getriggert werden, keine neuen Workflow Runs. Das ist ein eingebauter Sicherheitsmechanismus, um rekursive Loops zu verhindern. Wenn dein Workflow jedoch ein Personal Access Token nutzt, um Code zu committen oder Tags zu pushen, ist dieses Sicherheitsnetz weg. Der neue Commit triggert einen weiteren Workflow Run, der noch einen Commit macht und so eine Infinite Loop erzeugt. Wenn du unbedingt ein Personal Access Token nutzen musst, musst du extrem diszipliniert mit deinen Branch und Path Filtern sein, um sicherzustellen, dass der automatisierte Commit nicht die Trigger-Bedingungen für den Workflow erfüllt. Der effektivste Weg, deine Compute Costs zu optimieren, ist nicht, schnelleren Code zu schreiben, sondern einfach sicherzustellen, dass deine Workflows nur dann laufen, wenn sie es absolut müssen. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. GitHub Actions, Folge 4 von 14. Du versuchst, mit einer Runner Environment Variable festzulegen, ob ein Job starten soll, und deine Pipeline schlägt fehl, noch bevor überhaupt eine Maschine hochfährt. Du bist dir sicher, dass die Variable existiert, aber GitHub tut so, als wäre sie leer. Das Problem ist nicht deine Variable, es ist dein Timing. Um das zu fixen, müssen wir über State Evaluation mit Variablen und Contexts sprechen. In GitHub Actions wird der State deines Workflows in zwei völlig getrennten Phasen an zwei völlig verschiedenen Orten ausgewertet. Das ist der Kernunterschied zwischen einem Context und einer Environment Variable. Schauen wir uns zuerst Contexts an. Contexts sind Sammlungen von Informationen, die direkt von GitHub ausgewertet werden, bevor dein Workflow überhaupt an einen Runner geschickt wird. Sie enthalten Daten über den Workflow Run, das Repository, das Webhook Event, das den Run getriggert hat, und den User, der ihn gestartet hat. Weil GitHub Contexts sofort auswertet, kannst du sie nutzen, um die Struktur deiner Pipeline zu steuern. Du greifst auf einen Context über eine bestimmte Expression Syntax zu, normalerweise ein Dollarzeichen, gefolgt von doppelten geschweiften Klammern, die den Context-Namen enthalten. Default Environment Variables hingegen werden erst später ausgewertet, auf der eigentlichen Runner-Maschine, die deinen Job ausführt. Wenn der Runner hochfährt, setzt er automatisch verschiedene Default Environment Variables, wie den Repository-Namen oder den aktuellen Branch. Du greifst darauf genauso zu, wie du es in einem normalen Bash- oder PowerShell-Script tun würdest. Du kannst auch deine eigenen Environment Variables definieren, indem du den env Key in deinem Workflow File nutzt. Du kannst den env Key an einen kompletten Workflow, einen einzelnen Job oder einen bestimmten Step hängen. Hier ist die wichtigste Erkenntnis. Der Lifecycle bestimmt, was du wo verwenden kannst. Ein häufiger Fehler ist der Versuch, eine Runner Environment Variable innerhalb einer if Conditional auf Job-Ebene zu verwenden. Wenn du einem Job sagst, dass er nur laufen soll, wenn eine bestimmte Bash Environment Variable einem bestimmten Wert entspricht, wird der Workflow fehlschlagen. Der Runner ist noch gar nicht gestartet. Die Maschine existiert nicht, also existiert auch die Environment Variable nicht. Um Entscheidungen zu treffen, bevor der Runner hochfährt, musst du einen Context verwenden. Schauen wir uns ein praktisches Szenario an. Du möchtest, dass ein Deployment Job nur läuft, wenn der Code in den main Branch gemergt wird. Auf Job-Ebene schreibst du eine if Conditional. Du nutzt die Context Expression, um zu prüfen, ob der github dot ref Context dem String refs slash heads slash main entspricht. GitHub wertet das sofort aus. Wenn es true ist, stellt GitHub einen Runner bereit und schickt den Job dorthin. Sobald der Job auf dem Runner ist und deine Steps anfangen zu laufen, wechselst du zu Environment Variables. Innerhalb eines Bash Script Steps in demselben Job musst du vielleicht den Branch-Namen kennen, um ein Build Artifact zu taggen. Hier tippst du einfach ein Dollarzeichen, gefolgt von GITHUB underscore REF. Der Runner liest das aus seiner lokalen Operating System Environment. Du referenzierst exakt dieselben Daten, den Branch-Namen, aber du greifst über völlig unterschiedliche Mechanismen darauf zu, je nachdem, wo die Execution gerade stattfindet. Contexts routen den Workflow auf den GitHub-Servern. Environment Variables steuern die Execution Scripts auf dem Runner. Wenn du jemals mit leeren Variablen in deiner Workflow-Logik kämpfst, frag dich, ob die Maschine, die diese Logik auswertet, überhaupt schon hochgefahren ist. Wie immer, danke fürs Zuhören. Wir sehen uns in der nächsten Folge.

Hallo, hier ist Alex von DEV STORIES DOT EU. GitHub Actions, Folge 5 von 14. Entwickler erstellen oft langlebige Personal Access Tokens für einfache Repository-Tasks und hinterlassen so dauerhafte Credentials in ihrer Codebase. Aber für die meisten GitHub-Interaktionen musst du gar kein Token erstellen – in jedem Job wartet ein sicheres, kurzlebiges Token auf dich. Genau darum geht es in der heutigen Folge: Die Security Boundary: Secrets und GITHUB_TOKEN. Wenn du einen Workflow triggerst, stellt GitHub automatisch ein eindeutiges Secret namens GITHUB_TOKEN bereit. Das ist kein normales Personal Access Token. Es funktioniert als kurzlebiges GitHub App Installation Access Token. Es existiert ausschließlich für die Dauer des Workflow-Jobs. In dem Moment, in dem der Job endet, oder nach maximal 24 Stunden, läuft das Token ab und wird komplett nutzlos. Ein häufiger Fehler ist es, ein permanentes Personal Access Token zu generieren, nur damit ein Workflow einem Issue ein Label hinzufügt oder einen Kommentar in einem Pull Request postet. Das vergrößert deine Angriffsfläche unnötig. Das eingebaute GITHUB_TOKEN hat bereits die nötigen Permissions, um mit dem Repository zu interagieren, das den Workflow getriggert hat. Wenn dein Job einem Issue ein Label hinzufügen muss, übergibst du dieses eingebaute Token an den Step, der den API Call ausführt. Es werden niemals permanente Credentials erstellt, gespeichert oder offengelegt. Damit hätten wir die Interaktion mit GitHub selbst abgedeckt. Aber dein Workflow wird unweigerlich auch mit der Außenwelt kommunizieren müssen. Hier kommen verschlüsselte Custom Secrets ins Spiel. Wenn du ein Custom Secret erstellst, liegt es nicht als Plaintext auf einem GitHub-Server. Der Wert wird lokal über eine Libsodium Sealed Box verschlüsselt, bevor er überhaupt übertragen wird. Die Verschlüsselung basiert auf Public-Key-Kryptografie. Wenn du ein Secret über das Web-Interface oder die API hinzufügst, stellt GitHub einen Public Key bereit. Dein Client nutzt diesen Key, um die Box zu versiegeln. Nur die isolierte Runner Virtual Machine besitzt den dazugehörigen Private Key, der zum Öffnen dieser Box nötig ist, und sie entschlüsselt die Payload erst genau in dem Moment, in dem der Job ausgeführt wird. Du kannst diese verschlüsselten Secrets je nach Architektur auf verschiedenen Ebenen definieren. Repository-Level Secrets gelten für eine einzelne Codebase. Organization-Level Secrets erlauben es dir, ein einzelnes Credential, wie zum Beispiel ein Production-Datenbank-Passwort, über mehrere Repositories hinweg zu teilen. Das zentralisiert das Credential Management, erfordert aber strenge Kontrolle. Organization Secrets nutzen Access Policies, bei denen du explizit festlegst, welche Repositories das Secret lesen dürfen. Wenden wir das mal auf ein konkretes Szenario an. Angenommen, du hast ein Organization-Level Datenbank-Passwort, das für einen Datenbank-Migration-Step benötigt wird. Du willst nicht, dass dieses Passwort für den gesamten Workflow zugänglich ist. GitHub Actions erzwingt hier eine strenge Security Boundary. Secrets werden nicht automatisch in das Environment jedes Steps eingefügt. Du musst das Secret explizit auf eine Environment Variable in genau dem Step mappen, der es benötigt. Beim Schreiben des Workflow-Files greifst du über eine spezifische Context Reference auf den verschlüsselten Wert zu, rufst ihn aus dem Secrets-Objekt ab und weist ihn einer lokalen Environment Variable zu. Weil du es explizit gemappt hast, kann der Step vor der Migration das Passwort nicht sehen, und der Step danach kann es auch nicht sehen. Hier ist der entscheidende Punkt. Bei Security in der Automatisierung geht es darum, die Lebensdauer zu minimieren und den Scope einzuschränken. Verlasse dich für interne Repository Actions auf das kurzlebige GITHUB_TOKEN, um das Management permanenter Credentials zu vermeiden, und mappe verschlüsselte Secrets strikt nur auf die einzelnen Steps, die externen Zugriff benötigen. Das war's für diese Folge. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. GitHub Actions, Folge 6 von 14. Du richtest einen Multi-Job-Workflow ein, und um sicherzugehen, dass der zweite Job alles hat, was er braucht, bündelst du deinen kompletten Dependencies-Ordner und gibst ihn weiter. Aber plötzlich dauert dein Build fünf Minuten länger und dein Storage-Verbrauch schießt durch die Decke. Das Problem ist eine grundlegende Verwechslung von zwei unterschiedlichen Datenmechanismen, und genau darum geht es in dieser Folge: Datenoptimierung: Caching vs. Artifacts. Wir klären diese Verwirrung gleich mal auf. Caching und Artifacts verschieben zwar beide Dateien zwischen deinen GitHub Actions-Runnern, aber sie lösen völlig unterschiedliche Probleme. Stell dir Artifacts als das vor, was dein Workflow produziert. Und stell dir Caching als das vor, was dein Workflow konsumiert. Wenn du diese Rollen vertauschst, baust du unbemerkt einen Flaschenhals in deine gesamte Pipeline ein. Artifacts sind generierte Dateien, die du nach Abschluss eines Jobs behalten willst. Das kann eine kompilierte Binary, ein Test Coverage Report oder ein gezipptes Archiv deines finalen Build-Ordners sein. Sie existieren aus zwei Hauptgründen. Erstens, damit du den finalen Output deines Workflows herunterladen kannst, sobald er fertig ist. Zweitens, um generierte Daten zwischen verschiedenen Jobs innerhalb genau desselben Workflow Runs weiterzugeben. Weil jeder Job auf einer frischen virtuellen Maschine läuft, gehen alle in Job eins erstellten Dateien sofort verloren, wenn dieser Job endet, es sei denn, du lädst sie explizit hoch. Wenn du die Upload Artifact Action nutzt, speicherst du diese Dateien im GitHub Storage. Danach nutzt Job zwei die Download Artifact Action, um sie in seinen eigenen, sauberen Workspace zu ziehen. Vergleich das jetzt mal mit Dependency Caching. Caching ist eine reine Performance-Optimierung, die deinen Workflow über verschiedene Runs hinweg beschleunigen soll. Wenn du Software baust, lädst du normalerweise Tausende von Third-Party Dependencies herunter, wie zum Beispiel Packages von NPM oder pip. Diese bei jedem einzelnen Run übers Netzwerk abzurufen, ist langsam. Anstatt jedes Mal frische Dependencies herunterzuladen, speichert die Cache Action deinen heruntergeladenen Dependency-Ordner auf den Cache-Servern. Sie weist diesem Cache einen eindeutigen Key zu, fast immer basierend auf dem Hash deines Lockfiles. Beim morgigen Workflow Run prüft GitHub, ob das Lockfile mit einem existierenden Key übereinstimmt. Wenn das der Fall ist, wird der Ordner in Sekundenschnelle direkt in deinen Runner wiederhergestellt und die Package Registry komplett umgangen. Hier ist der entscheidende Punkt. Der größte Fehler, den du machen kannst, ist die Upload Artifact Action zu nutzen, um einen riesigen Dependency-Ordner wie node_modules zwischen Jobs zu verschieben. Artifacts verarbeiten Daten, indem sie sie zippen, hochladen, herunterladen und entzippen. Das mit Zehntausenden von winzigen Textdateien zu machen, fügt deiner Runtime massive Netzwerk-Latenz hinzu und frisst deine Account Storage Quotas auf. Artifacts sind nicht für pure Geschwindigkeit gebaut; sie sind für sicheren Datentransfer und dauerhafte Aufbewahrung gedacht. Caches hingegen sind hochoptimiert, um große Dependency Trees schnell zu ziehen, und sie veralten automatisch und löschen sich selbst, um Platz zu sparen. Stell dir eine saubere Pipeline vor, die beides richtig nutzt. Du hast einen Workflow mit einem Build-Job und einem Deploy-Job. Im Build-Job nutzt dein erster Step die Cache Action, um deine NPM Dependencies vom gestrigen Run sofort wiederherzustellen. Dein Code kompiliert schnell und produziert eine finale Application Binary. Dann nutzt du die Upload Artifact Action, um nur diese eine Binary-Datei zu speichern. Der Build-Job endet und der Runner wird zerstört. Der Deploy-Job startet auf einem neuen Runner. Er braucht weder den Cache noch die NPM Dependencies. Er nutzt einfach die Download Artifact Action, um sich die kompilierte Binary zu schnappen, die du gerade gebaut hast, und pusht sie dann auf deinen Production Server. Caching ist ein temporärer Shortcut für Dinge, die du herunterlädst, während Artifacts die essenzielle Übergabe für Dinge sind, die du erstellst. Danke fürs Dabeisein. Ich hoffe, du hast etwas Neues mitgenommen.

Hallo, hier ist Alex von DEV STORIES DOT EU. GitHub Actions, Folge 7 von 14. Ein Entwickler pusht innerhalb von fünf Minuten drei Commits in schneller Folge in einen offenen Pull Request. Wenn dein CI-Server drei redundante Test Suites durchackert, verbrennst du Geld. Du brauchst einen Weg, dem System zu sagen, dass nur der neueste Code zählt, und genau das macht die Flow-Steuerung mit Concurrency. Standardmäßig führt GitHub Actions getriggerte Workflows parallel aus. Wenn du fünfmal pushst, startet es fünf unabhängige Runner. Bei einfachen Checks verschwendet das Runner-Minuten. Bei Deployments ist das sogar richtig gefährlich. Wenn zwei Workflow Runs gleichzeitig versuchen, in dieselbe Staging-Umgebung zu deployen, erzeugst du eine Race Condition. Der ältere Commit könnte sogar nach dem neueren fertig deployen, deine Updates überschreiben und deine Umgebung in einem veralteten State hinterlassen. Das fixt du mit dem Concurrency Keyword. Du kannst es auf dem Top-Level des gesamten Workflows anwenden oder auf einen bestimmten Job beschränken. Der Mechanismus basiert komplett auf Concurrency Groups. Eine Concurrency Group ist einfach nur ein String, den du definierst. Wenn zwei Runs exakt denselben Gruppennamen teilen, erzwingt GitHub Concurrency Limits zwischen ihnen. Viele machen den Fehler, diesen String zu hardcoden. Wenn du den Gruppennamen einfach nur auf das Wort deploy setzt, bricht ein Push in deinen Testing Branch ein aktives Deployment auf deinem Main Production Branch ab. Der Gruppenname muss dynamisch sein. Du baust ihn mit Context-Variablen zusammen, wie zum Beispiel der aktuellen Branch-Referenz. Wenn du die Gruppe nach der Pull Request Nummer benennst, gelten die Concurrency Limits nur für Pushes innerhalb dieses spezifischen Pull Requests. Dein Main Branch bleibt davon komplett unberührt. Wenn ein neuer Workflow getriggert wird, checkt GitHub, ob für diese Concurrency Group bereits ein Run aktiv ist. Wenn ja, ist das Standardverhalten, den neuen Run in einen Pending State zu versetzen. Er wartet in einer Queue. Hier ist der entscheidende Punkt. Die Queue hält immer nur einen Pending Job. Wenn ein dritter Run getriggert wird, während der erste läuft und der zweite pending ist, fliegt der zweite Run aus der Queue. Nur der absolut neueste Run darf warten. Warten ist für Deployments sicherer, aber beim Pull Request Testing frisst Warten immer noch unnötig Zeit. Hier kommt das cancel-in-progress Setting ins Spiel. Das ist ein Boolean Flag, das du unter deiner Concurrency Group Definition hinzufügst. Wenn du cancel-in-progress auf true setzt, änderst du das Verhalten von Queuing auf Terminating. Denk nochmal an den Entwickler, der drei Commits in schneller Folge pusht. Der erste Push triggert eine Test Suite. Zwei Minuten später pusht er nochmal. Weil du die Concurrency Group auf den Branch-Namen gesetzt und cancel-in-progress aktiviert hast, sieht GitHub den neuen Run, terminiert sofort die aktive Test Suite für den ersten Commit und startet das Testing für den zweiten Commit. Wenn eine Minute später der dritte Push passiert, terminiert es den zweiten Run und startet den dritten. Der Entwickler bekommt am Ende immer noch sein Pass oder Fail, aber du hast nur einmal für die Ausführung der Tests bezahlt. Concurrency Controls verwandeln deine CI-Pipelines von einem reaktiven System, das blind jeden Trigger ausführt, in ein State-aware System, das Ressourcen nur für den Code ausgibt, der wirklich zählt. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. GitHub Actions, Folge 8 von 14. Die Credentials deiner Production-Datenbank sollten niemals für einen zufälligen Pull Request aus einem Feature Branch zugänglich sein. Wenn jedoch alle deine Secrets auf Repository-Ebene gespeichert sind, kann potenziell jeder Workflow darauf zugreifen. Genau deshalb brauchst du Gating Deployments mit Environments, um diese Sicherheitslücke zu schließen. Zuerst müssen wir ein häufiges Missverständnis ausräumen. Ein Environment in GitHub Actions ist kein physischer Server. GitHub fährt für dich keine virtuelle Maschine oder Cloud-Instanz namens Production hoch. Ein Environment ist lediglich eine logische Grenze, die in den Settings deines GitHub-Repositorys konfiguriert wird. Es fungiert als Gatekeeper und steuert, wann ein Job laufen darf und welche Daten dieser Job sehen darf. Der Hauptgrund, warum dieses Feature existiert, ist die Durchsetzung von Release Governance und der Schutz sensibler Daten. Wenn du ein Environment erstellst, kannst du ihm direkt spezifische Secrets und Variablen zuweisen. Du könntest zum Beispiel ein Environment namens Staging und ein weiteres namens Production erstellen. Jedes bekommt sein eigenes, einzigartiges Set an API-Keys, die unter exakt demselben Variablennamen gespeichert sind. In deinem Workflow-File verknüpfst du einen bestimmten Job mit einem Environment, indem du einfach dessen Namen angibst. Wenn der Workflow läuft, bekommt der Job, der das Staging-Environment referenziert, die Staging-Keys. Der Job, der das Production-Environment referenziert, bekommt die Live-Keys. Das isoliert deine sensiblen Daten komplett. Ein Job, der in einem Feature Branch läuft, kann die Production-Keys nicht lesen, weil er nicht im Kontext des Production-Environments läuft. Aber das Isolieren von Secrets ist nur die halbe Stärke von Environments. Die andere Hälfte sind Protection Rules. Diese Rules fungieren als strenge Gates in deiner Deployment-Pipeline. Die häufigste Protection Rule ist ein Required Reviewer. Schauen wir uns an, wie das in einem echten Szenario abläuft. Du hast einen Workflow, der deine Applikation baut und automatisch auf Staging deployt. Dieser Job läuft erfolgreich durch. Der nächste Job im Workflow ist für das Deployment auf Production konfiguriert und referenziert dein Production-Environment. Wenn du für dieses Environment eine Required Reviewer Rule eingerichtet hast, stoppt der Workflow genau an dieser Stelle. Der Job pausiert. Er wird nicht an einen Runner dispatched, und die Production-API-Keys bleiben sicher weggesperrt. GitHub schickt eine Notification an den zuständigen Manager oder das Team, um zu signalisieren, dass ein Deployment wartet. Der Workflow bleibt in diesem Pending-Status, bis jemand aktiv wird. Erst wenn der Manager im GitHub-Interface auf Approve klickt, öffnet sich das Gate. Genau in diesem Moment wird der Job an einen verfügbaren Runner dispatched, die Production-Secrets werden entschlüsselt und injected, und das Deployment-Script wird ausgeführt. Du kannst noch weitere Protection Rules über die manuellen Approvals legen. Eine Option ist ein Wait Timer, der einen Job zwingt, eine bestimmte Anzahl von Minuten zu warten, bevor er startet. Das gibt dir einen Puffer, um einen Rollout abzubrechen, falls du direkt nach einem Staging-Deployment einen Anstieg der Fehlerraten auf deinen Monitoring-Dashboards bemerkst. Du kannst auch Deployment Branches konfigurieren. Das schränkt das Environment so ein, dass es nur Jobs akzeptiert, die von bestimmten Branches laufen, wie deinem Main Branch oder bestimmten Release Tags. Wenn ein Entwickler versucht, einen Deployment-Job aus einem beliebigen Bugfix Branch auf Production zu erzwingen, lehnt das Environment Gate den Run einfach ab. Hier ist die wichtigste Erkenntnis. Environments entkoppeln deine Deployment-Mechanik von deiner Access Control. Dein Workflow-File beschreibt die exakten Schritte, die nötig sind, um deinen Code zu deployen, aber die Environment-Settings in GitHub legen fest, wer die Berechtigung dazu hat und welche Secrets dabei freigeschaltet werden. Wenn dir diese technischen Deep Dives gefallen, kannst du die Show unterstützen, indem du auf Patreon nach DevStoriesEU suchst. Danke fürs Zuhören und Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. GitHub Actions, Folge 9 von 14. Die sichersten Cloud-Credentials sind die, die fünf Minuten nach Abschluss deines Deployments ablaufen. Trotzdem kopieren viele Teams weiterhin langlebige Administrator-Keys in die Repository-Settings und hoffen, dass sie nie leaken. Heute fixen wir das, indem wir uns Passwordless Cloud Access via OIDC anschauen. Bisher bedeutete die Verbindung eines GitHub-Workflows mit einem Cloud-Provider, einen Access Key in AWS, Google Cloud oder Azure zu generieren und ihn als langlebiges GitHub Secret zu speichern. Wenn dieses Secret geleakt ist, konnte es jeder von überall aus nutzen, bis ein Administrator es manuell revoked hat. Viele denken, OpenID Connect, oder OIDC, ist einfach eine neue Art von Secret, das man in sein Repository reinkopiert. Ist es aber nicht. OIDC ersetzt gespeicherte Secrets komplett. Es ist ein Protokoll, das on the fly ein dynamisches, kryptografisches Token generiert, um die Workflow-Identity gegenüber deinem Cloud-Provider nachzuweisen. GitHub fungiert dabei als OIDC Identity Provider. Wenn ein Workflow läuft, kann er GitHub auffordern, ein JSON Web Token, oder JWT, auszustellen. Damit das passiert, musst du deinem Workflow-File eine bestimmte Permission hinzufügen. Du setzt den Permissions-Block so, dass Write-Access für das ID-Token erlaubt ist. Das sagt GitHub, dass der Workflow autorisiert ist, ein Identity Credential zu generieren. Hier ist der entscheidende Punkt: Dieses Token allein gewährt noch keinen Access. Es ist einfach ein digital signiertes Dokument, das Claims enthält. Claims sind Metadaten, die überprüfbare Fakten über den aktuell laufenden Workflow festhalten. Das Token enthält den Repository-Namen, die Organization, den Branch, das Environment und das Event, das den Run getriggert hat. Weil GitHub das Token kryptografisch signiert, kann dein Cloud-Provider diesen Claims vertrauen. Das bildet die Grundlage für ein Zero-Trust-Deployment. Schauen wir uns einen Deployment-Job an, der ein Image in eine AWS Elastic Container Registry pusht. Der Workflow startet und fordert ein OIDC-Token von GitHub an. Das Token wird generiert und enthält Claims, die verifizieren, dass es vom Main Branch deines Backend-Repositorys kommt. Der Workflow sendet dieses Token dann an AWS. AWS checkt zuerst die digitale Signatur, um sicherzustellen, dass das Token wirklich von GitHub kommt. Dann liest es die Claims. Es gleicht diese Claims mit einer strengen Trust Policy ab, die du vorher definiert hast. Die Policy könnte besagen, dass sie nur Tokens aus deinem spezifischen Repository akzeptiert, und auch nur dann, wenn der Workflow auf dem Main Branch läuft. Weil die Claims matchen, akzeptiert AWS das Token. AWS gibt keinen permanenten Key zurück. Stattdessen stellt es ein temporäres Access Token aus. Dieses Token ist vielleicht nur fünfzehn Minuten gültig. Dein Workflow nutzt dieses temporäre Credential, um das Container-Image in die Registry zu pushen. Wenn der Job durch ist, läuft das Credential ab. Es gibt nichts zu rotieren und nichts in GitHub Gespeichertes, das ein Angreifer extrahieren könnte. Wenn du das aufsetzt, achte genau auf den Subject Claim, oft auch Sub Claim genannt. Das ist das primäre Feld, das Cloud-Provider nutzen, um den Access zu filtern. Standardmäßig formatiert GitHub den Subject Claim so, dass er den Repository-Namen und die Git-Reference enthält, wie zum Beispiel den Branch oder Tag. Du musst sicherstellen, dass deine Cloud Trust Policy diesen Subject Claim strikt validiert. Wenn du nur den Organization-Namen checkst, könnte jedes Repository in deiner Organization Cloud-Resources anfordern. Indem du temporären Cloud-Access mit spezifischen Workflow-Metadaten verknüpfst, garantierst du, dass ein kompromittiertes Repository deine Infrastructure nicht anfassen kann, es sei denn, der Request kommt von genau dem Branch und dem Environment, denen du explizit vertraust. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. GitHub Actions, Folge 10 von 14. Wenn du Continuous Integration über fünfzig Repositories hinweg verwaltest, ist Copy-and-Paste der exakt gleichen YAML-Dateien ein absoluter Wartungs-Albtraum. Du änderst ein Security-Scanning-Tool, und plötzlich musst du fünfzig separate Dateien manuell updaten. In dieser Folge geht es um Scaling DRY Pipelines, um genau das zu lösen. Um dich in GitHub Actions nicht ständig zu wiederholen, hast du zwei Hauptwerkzeuge: Reusable Workflows und Composite Actions. Entwickler wählen oft das falsche, weil beide Duplikate vermeiden. Eine Composite Action ist kein Workflow. Sie ist einfach ein Bundle von Steps. Ein Reusable Workflow ist eine komplette Pipeline, die ganze Jobs bündelt. Wenn deine geteilte Logik über mehrere Maschinen laufen, komplexe Dependencies zwischen Jobs orchestrieren oder Secrets sicher verwalten muss, musst du einen Reusable Workflow nutzen. Eine Composite Action nimmt eine Sequenz von Steps – wie Code auschecken, eine Language-Environment aufsetzen und Dependencies installieren – und packt sie in eine einzige Custom Action. Wenn ein Workflow diese Action nutzt, werden all diese gebündelten Steps nacheinander innerhalb des aktuell existierenden Jobs ausgeführt. Die Composite Action entscheidet nicht, auf welcher Runner-Maschine sie ausgeführt wird. Sie läuft dort, wo der Parent-Job sie platziert. Sie existiert nur, um repetitive Step-Logik innerhalb einer einzigen Execution-Environment aufzuräumen. Reusable Workflows arbeiten auf einer viel höheren Architektur-Ebene. Sie sind komplette YAML-Dateien, die ein anderer Workflow triggern kann. Der Workflow, der den Request macht, ist der Caller-Workflow, und der getriggerte Workflow ist der Called-Workflow. Weil ein Called-Workflow ganze Jobs definiert, kontrolliert er die Infrastruktur. Ein Job innerhalb des Reusable Workflows könnte auf einem Ubuntu-Runner laufen, um eine Applikation zu builden, während ein abhängiger Job auf einem macOS-Runner läuft, um sie zu testen. Stell dir ein Platform-Engineering-Team vor, das eine Node-Deployment-Pipeline standardisiert. Sie wollen sicherstellen, dass jedes Team identische Security-Checks ausführt, bevor Code geshippt wird. Anstatt darauf zu vertrauen, dass fünfzig Produkt-Teams identische YAML-Dateien pflegen, erstellen die Platform-Engineers einen zentralen Reusable Workflow in einem Shared-Repository. Diese zentrale Datei definiert die exakte Sequenz von Jobs, die nötig sind, um die Applikation zu scannen, zu builden und zu deployen. Die fünfzig Produkt-Repositories erstellen dann einen minimalen Caller-Workflow. Dieser Caller-Workflow enthält nur einen einzigen Job, der über seinen Pfad direkt auf das Shared-File des Platform-Teams zeigt. Du gibst Konfigurationsdaten über Inputs an den Called-Workflow weiter und spezifizierst Parameter wie den Namen der Target-Environment oder die Node-Version. Der Caller-Workflow kann auch Secrets weitergeben. Du kannst spezifische Secrets explizit mappen oder den Called-Workflow anweisen, einfach alle Secrets zu erben, die dem Caller zur Verfügung stehen. Wenn das Platform-Team ein Deployment-Secret rotieren oder ein neues Static-Analysis-Tool hinzufügen muss, updaten sie den zentralen Called-Workflow. Sofort führen alle fünfzig Repositories beim nächsten Commit den neuen Security-Check aus. Die Produkt-Teams müssen absolut keine Konfiguration anfassen. Hier ist die wichtigste Erkenntnis: Nutze Composite Actions, um chaotische Step-Logik innerhalb einer einzigen Environment zu verstecken, aber nutze Reusable Workflows, um standardisierte Pipeline-Architekturen in deiner gesamten Organisation durchzusetzen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. GitHub Actions, Folge 11 von 14. Ein Container garantiert zwar exakte Tool-Versionen, verursacht aber bei jedem einzelnen Workflow Run versteckte Latenzkosten. Die Konsistenz deiner Umgebung kann dein Team ausbremsen und es an ein einzelnes Betriebssystem binden, ohne dass du es überhaupt merkst. Crafting Custom Actions: Docker vs JavaScript löst dieses Problem. Eine Custom Action ist wiederverwendbare Logik, die du einmal schreibst und über mehrere Repositories hinweg teilst. Wenn du eine baust, musst du dich für eine Ausführungsarchitektur entscheiden. Die beiden Hauptmodelle sind JavaScript und Docker. Viele Entwickler greifen standardmäßig zu Docker Actions, weil sie absolute Sicherheit und vorhersehbare Dependencies wollen. Sie gehen davon aus, dass ein Container die robusteste Wahl ist. Die Realität ist jedoch, dass der Bau einer Docker Action macOS- oder Windows-Runner dauerhaft davon ausschließt, dein Tool zu nutzen. Docker Actions werden ausschließlich in Linux-Umgebungen ausgeführt. JavaScript Actions verfolgen einen anderen Ansatz. Sie werden direkt auf der Host-Maschine ausgeführt. Du schreibst deine Logik, kompilierst sie mit all ihren Dependencies zu einer einzigen Datei und verweist in den Action-Metadaten auf dieses Entry-File. Wenn ein Workflow triggert, nutzt der Runner seine integrierte Node-Runtime, um dein Skript auszuführen. Das entkoppelt deine Logik vom zugrundeliegenden Betriebssystem. Exakt dieselbe Action läuft ohne Anpassungen nativ auf Linux-, macOS- und Windows-Runnern. Docker Container Actions hingegen bündeln das Betriebssystem, die System-Dependencies und deinen Code zu einer unveränderlichen Einheit. Du bestimmst die exakte Umgebung. Der Runner liest ein von deiner Action bereitgestelltes Dockerfile, baut oder pullt das Container-Image und führt deinen Code in diesem isolierten Bereich aus. Hier ist der entscheidende Punkt. Die strikte Isolation einer Docker Action bringt eine Cold-Start-Penalty mit sich. Stell dir ein Team vor, das ein Custom Code-Linting-Tool baut, um es in der gesamten Organisation zu teilen. Wenn sie es als Docker Action bauen, muss der Runner dieses Container-Image pullen, bevor er auch nur eine einzige Zeile Code auswerten kann. Das kann den Start jedes Linting-Jobs um fünfzehn Sekunden verzögern. Bei hunderten von Pull Requests am Tag summiert sich diese Leerlaufzeit zu stundenlanger, verschwendeter Rechenzeit. Wenn das Team exakt dieselbe Linting-Logik in JavaScript baut, lädt der Runner die Skriptdatei einfach herunter und führt sie sofort aus. Deine Wahl der Architektur bestimmt, wie sich deine Action in der Praxis verhält. Wenn dein Tool auf komplexe System-Binaries angewiesen ist, eine sehr spezifische Version eines Compilers benötigt oder alte Bash-Skripte wrappt, die außerhalb einer bestimmten Linux-Distribution fragil sind, ist Docker die richtige Wahl. Du zahlst diese Latenz-Steuer im Austausch für garantierte Stabilität. Wenn es dein Ziel ist, ein schnelles, weit verbreitetes Tool zu bauen, das für jeden Projekttyp funktioniert, ist JavaScript der bessere Weg. Die architektonische Entscheidung zwischen Docker und JavaScript für eine Custom Action dreht sich nie darum, in welcher Programmiersprache du lieber schreibst. Es ist ein harter Trade-off zwischen strikter Umgebungskontrolle und plattformübergreifender Ausführungsgeschwindigkeit. Das war's für diese Folge. Wir hören uns beim nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. GitHub Actions, Folge 12 von 14. GitHub Cloud Runner sind extrem praktisch, bis deine Integration Tests auf eine Legacy-Datenbank zugreifen müssen, die sicher hinter einer Corporate Firewall versteckt ist. Plötzlich kann ein Public Runner deine privaten Daten nicht mehr erreichen. Genau hier kommt Fleet Management ins Spiel: Hosted vs Self-Hosted Runners. Standardmäßig nutzen GitHub Actions GitHub-hosted Runners. Wenn ein Workflow triggert, fährt GitHub eine frische Virtual Machine hoch. Du kannst Ubuntu, Windows oder macOS anfordern. Der Runner führt deinen Job aus, meldet das Ergebnis, und danach wird die Virtual Machine sofort wieder zerstört. Es ist jedes einzelne Mal eine komplett saubere Umgebung. Du musst weder das Betriebssystem verwalten, noch Security Patches installieren, und du musst dir keine Sorgen um übrig gebliebene Dateien von einem vorherigen Build machen. Diese Isolation ist jedoch ein zweischneidiges Schwert. Da diese Runner in der GitHub Cloud-Infrastruktur existieren, arbeiten sie mit dynamischen IP-Adressen und haben keinen direkten Zugriff auf deine privaten Netzwerke. Wenn du eine interne Applikation oder eine Datenbank hast, die nicht dem öffentlichen Internet ausgesetzt werden darf, brauchst du einen Runner, der innerhalb deines eigenen Sicherheitsbereichs lebt. Das ist ein Self-Hosted Runner. Du stellst die Hardware bereit. Das kann ein physischer Server in einem Rechenzentrum, eine Virtual Machine bei deinem Cloud Provider oder ein Container sein. Du installierst die GitHub Actions Runner-Applikation auf dieser Maschine. Der Runner verbindet sich nach außen mit GitHub, ruft ausstehende Jobs ab, führt sie lokal aus und sendet die Logs zurück. Weil er in deinem Netzwerk lebt, kann er sicher mit deiner internen Infrastruktur kommunizieren, ohne Löcher in deine Firewall zu bohren. Hier ist die entscheidende Erkenntnis. Dir gehört die Hardware, was bedeutet, dass du auch für die Maintenance verantwortlich bist. Du bist verantwortlich für Betriebssystem-Updates, Netzwerksicherheit und die Installation notwendiger Dependencies wie Language Runtimes oder Build Tools. Ein häufiges Missverständnis ist, dass sich Self-Hosted Runner genau wie die Hosted Runner verhalten. Das tun sie nicht. GitHub-hosted Runner sind by design ephemeral. Standard Self-Hosted Runner sind stateful. Wenn ein Job auf einem Default Self-Hosted Runner durchgelaufen ist, läuft die Maschine einfach weiter. Wenn dein Job eine temporäre Datei schreibt, einen Hintergrundprozess startet oder ein großes Container Image pullt, bleibt all das auf der Festplatte, wenn der nächste Job startet. Das birgt ernsthafte Risiken für Cross-Contamination. Ein fehlerhaftes Build Script in einem Pull Request könnte beschädigte Dateien hinterlassen, wodurch der Deployment Job, der direkt danach läuft, fehlschlägt. Du musst deine Self-Hosted Infrastruktur aktiv so konfigurieren, dass sie ephemeral ist, wenn du das möchtest – oft indem du Webhooks nutzt, um für jeden Job frische Container hochzufahren. Wenn du einfach mehr Rechenleistung oder eine statische IP-Adresse brauchst, aber trotzdem willst, dass GitHub die Machine Maintenance übernimmt, gibt es einen Mittelweg namens Larger Runners. Das sind GitHub-hosted Maschinen, bei denen du die Hardware-Spezifikationen und Netzwerk-Features definierst, aber sie bleiben ephemeral und werden von GitHub gemanagt. Letztendlich geht es bei der Entscheidung zwischen Hosted und Self-Hosted selten nur um Compute Costs. Es ist ein grundlegender Trade-off zwischen dem Komfort einer Zero-Maintenance, Disposable Umgebung und der Notwendigkeit, deine eigenen Netzwerkgrenzen zu kontrollieren. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. GitHub Actions, Folge 13 von 14. Du hast ein riesiges Team, und morgens um neun pushen hundert Entwickler gleichzeitig Code. Deine statischen Build-Server brechen entweder unter der Queue zusammen, oder du hast sie überdimensioniert und sie sitzen da und verschwenden die ganze Nacht teures Compute. Kubernetes Scale: Actions Runner Controller löst dieses Problem, indem er deine Build-Pipeline in ein dynamisches, container-natives System verwandelt. Standard Self-Hosted Runners sind normalerweise statische virtuelle Maschinen oder langlebige Container. Du richtest sie ein, registrierst sie an einem Repository, und dann sitzen sie da und pollen nach Arbeit. Dieses Setup garantiert, dass du für Idle-Time bezahlst, und bei einem plötzlichen Spike bei den Builds staut sich deine Queue einfach zurück, bis ein existierender Runner seinen aktuellen Task beendet hat. Actions Runner Controller, oder ARC, ändert dieses Modell grundlegend. ARC ist ein Kubernetes Operator, der Auto-Scaling Runner Scale Sets orchestriert. Anstatt langlebige Worker Nodes zu maintainen, provisioniert er ephemeral Just-in-Time Runners, basierend auf der exakten Größe deiner Queue. Um das durchzuziehen, ohne die API Rate Limits zu überlasten, verlässt sich ARC auf zwei zentrale Architekturkomponenten in deinem Kubernetes Cluster. Die erste ist der Listener Pod. Der Listener nutzt einen HTTPS Long Poll, um sich mit GitHub zu verbinden. Anstatt dass du Inbound Firewall Ports öffnen musst, um Webhooks zu empfangen, verbindet sich der Listener mit GitHub und hält die Connection offen. Er sitzt einfach leise da und wartet darauf, dass GitHub eine Job Available Message nach unten weitergibt. Wenn der Listener diese Message empfängt, gibt er die Informationen an den Controller Pod weiter. Der Controller fungiert als Provisioning Engine. Er spricht sofort mit der Kubernetes API, um einen brandneuen Runner Pod speziell für diesen einen Pending Job hochzufahren. Dieser Pod ist ein ephemeral Just-in-Time Runner. Er bootet, empfängt ein kurzlebiges Registration Token, führt den Workflow aus und terminiert sich dann sofort selbst. Schauen wir noch mal auf diesen Code Rush um neun Uhr morgens. Hundert Entwickler pushen exakt zur gleichen Zeit Commits. Der Listener Pod erkennt den plötzlichen Burst an Job Available Messages von GitHub. Er alarmiert den Controller, der sofort hundert ephemeral Kubernetes Pods anfordert. Dein Cluster skaliert out, allokiert Nodes falls nötig, und die Jobs werden parallel ausgeführt. Sobald jeder Workflow abgeschlossen ist, wird sein Pod komplett zerstört. Um neun Uhr fünfzehn ist die Queue leer, und dein Runner Count skaliert wieder komplett auf null zurück. Du hast für exakt fünfzehn Minuten massives paralleles Compute genutzt und dann aufgehört, dafür zu bezahlen. Hier ist die entscheidende Erkenntnis. Weil jeder einzelne Job in einem frisch provisionierten, isolierten Pod läuft, der direkt nach der Execution zerstört wird, eliminierst du State Contamination zwischen den Builds komplett. Ein Dirty Cache, ein übrig gebliebener Background Process oder eine veränderte Environment Variable aus einem vorherigen Run können den nächsten einfach nicht kaputt machen. Du gewinnst jedes Mal die Sicherheit einer makellosen Build-Umgebung, gekoppelt mit der exakten Compute-Effizienz von Kubernetes Auto-Scaling. Der wahre Wert des Actions Runner Controllers ist, dass er dich davon abhält, Continuous Integration Runners als schwere Infrastruktur zu behandeln, die du maintainen musst. Stattdessen verwandelt er sie in rein transientes Compute, das nur existiert, während ein Job aktiv läuft. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. GitHub Actions, Folge 14 von 14. Ein User lädt dein kompiliertes Command Line Tool von einer Release-Seite herunter. Wenn eine kompromittierte Dependency oder ein Angreifer das Binary nach dem Build ausgetauscht hat, hilft ein Standard-Checksum-Check nicht weiter. Standard-Hashes beweisen nur, dass die heruntergeladene Datei mit der gehosteten Datei übereinstimmt, aber nicht, woher sie tatsächlich kommt. Um zu garantieren, dass eine Datei aus genau deinem Code generiert wurde, brauchst du Supply Chain Integrity mit Attestations. Eine Attestation ist nicht einfach nur ein Build-Log oder eine Textdatei mit einem Hash, die neben deinem Release liegt. Sie ist ein kryptografisch signierter, fälschungssicherer Nachweis über die Provenance eines Artifacts. Sie verknüpft dein finales Binary direkt mit dem exakten Commit-SHA, dem spezifischen Workflow Run und der OpenID Connect-Identität der Build-Umgebung. Der gesamte Prozess findet komplett innerhalb deines GitHub Actions Workflows statt. Nachdem dein Code kompiliert ist, nutzt du die offizielle Build Provenance Action. Diese Action berechnet die Checksum deines fertigen Artifacts und kontaktiert eine zentrale Signing Authority, genauer gesagt Sigstore. Der Workflow tauscht sein temporäres, Job-spezifisches OpenID Connect Token gegen ein kurzlebiges Signing-Zertifikat ein. Da dieses Token von GitHub Actions ausgestellt und direkt deinem Repository zugeordnet wird, dient es als fälschungssicherer Identitätsnachweis für den Workflow Runner. Diese Interaktion erzeugt einen permanenten kryptografischen Record. Dieser Record belegt eindeutig, dass genau dieser File-Hash von deinem Repository produziert wurde, getriggert durch einen bestimmten Commit, während eines bestimmten Workflow Runs. Die Signatur wird an das Artifact angehängt und bildet so ein Beweispaket, das mit der Datei mitreist, egal wo sie gehostet wird. Hier ist die entscheidende Erkenntnis: Der eigentliche Sicherheitswert entsteht auf der Consumer-Seite. Wenn ein User dein Command Line Tool herunterlädt, muss er dem Hosting-Provider oder dem Download-Mirror nicht blind vertrauen. Bevor er das Binary ausführt, nutzt er die GitHub CLI, um die Attestation lokal zu verifizieren. Er führt einen Attestation Verify Command gegen das heruntergeladene Executable aus und gibt dabei explizit deinen Repository Owner als erwartete Quelle an. Die CLI prüft die kryptografische Signatur und gleicht sie mit dem öffentlichen Transparency Log ab. Ist die Signatur gültig, beweist das mathematisch, dass die Datei durch deinen offiziellen Workflow kompiliert wurde. Wenn ein böswilliger Akteur den Download abgefangen, die Kompilierung manipuliert oder das Binary auf der Release-Seite ersetzt hat, schlägt die Verification sofort fehl. Die Signatur kann nicht gefälscht werden, da der Angreifer niemals in den Besitz des temporären OpenID Connect Identity Tokens kommen kann, das innerhalb deines sicheren Workflow Runs generiert wird. Die Identität ist genau im Moment des Builds untrennbar mit der GitHub Actions Infrastruktur verbunden. Dieser Mechanismus schließt eine kritische Lücke in der Software Supply Chain Security. Du verlangst von den Usern nicht länger, einer Storage Location zu vertrauen. Stattdessen wird das Artifact selbstauthentifizierend. Attestations verändern dein Security-Modell: Anstatt darauf zu vertrauen, wo eine Datei liegt, wird mathematisch bewiesen, wo sie entstanden ist. Da dies die letzte Folge unserer GitHub Actions-Serie ist, möchte ich dir dringend empfehlen, selbst hands-on zu werden und diese Workflows selbst zu bauen. Besuche DEV STORIES DOT EU, um Themen vorzuschlagen, die du in unseren zukünftigen Serien sehen möchtest. Das war's für diese Folge. Danke fürs Zuhören und keep building!