GitHub Actions ist von der Warnung zum tatsächlichen Fehlerfall übergegangen: Node 20 steht auf von GitHub gehosteten Runnern nicht mehr als Laufzeit für JavaScript-Actions zur Verfügung. Seit dem 23. September 2026 laufen diese Actions mit Node 24; auch die vorübergehende Ausnahme, mit der Repositories Node 20 weiterverwenden konnten, wurde entfernt.

Redaktionelle Technologieillustration eines Open-Source-Maintainers, der die Migration von GitHub Actions von Node 20 auf Node 24 mit CI-Artefakten und einem selbst gehosteten Runner prüft.

Für die meisten Repositories wirkt die sichtbare Korrektur zunächst einfach: Action-Referenzen aktualisieren und weitermachen. Für Open-Source-Maintainer reicht das jedoch nicht. Eine Action kann im Quellbaum gesund aussehen, während ihr veröffentlichtes Tag noch auf ein altes dist-Bundle zeigt. Ein Workflow kann eine aktuelle JavaScript-Action verwenden und trotzdem auf einem Self-Hosted-Runner, einem älteren Mac oder einem ARM32-Board scheitern. Lokale Werkzeuge, die Actions emulieren, können weiterhin die falsche Laufzeit ausführen und dadurch einen falschen Eindruck von Kompatibilität erzeugen.

Die praktische Konsequenz lautet: Das Thema sollte als Prüfung von Release- und Support-Matrix behandelt werden, nicht als bloßes Ersetzen von node20 durch node24 in einer Zeile. Die Laufzeitumstellung ist das unmittelbare Ereignis. Das dauerhaftere Problem betrifft die Frage, wie Open-Source-Projekte unterstützte Runner kommunizieren, unveränderliche Action-Artefakte veröffentlichen und die Umgebungen testen, die ihre Nutzer tatsächlich einsetzen.

Was sich am 23. September geändert hat

In GitHubs Rückzugsmitteilung steht, dass Runner nun Node 24 für JavaScript-Actions verwenden. Außerdem ist ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION nicht mehr verfügbar. Diese Variable war während der Umstellung ein vorübergehender Ausweg; als unterstützter Kompatibilitätsmechanismus taugt sie jetzt nicht mehr. GitHub wendet die Änderung auf github.com und GitHub mit Data Residency an.

Wichtig ist die Unterscheidung zwischen der Laufzeit einer Action und der Node-Version, die für einen Workflow installiert wird. Eine JavaScript-Action legt ihre Ausführungslaufzeit in action.yml fest, typischerweise in einem Block wie diesem:

runs:
  using: node24
  main: dist/index.js

Diese Einstellung bestimmt, welche Node-Laufzeit GitHub zum Starten der Action verwendet. Sie ist unabhängig von einem späteren Schritt wie actions/setup-node, der eine Node-Version für Befehle im eigenen Build-, Test- oder Packaging-Prozess des Repositories installiert. Node 20 mit setup-node zu installieren, macht eine Action mit der Deklaration node20 nicht kompatibel mit einem Runner, auf dem die Node-20-Action-Laufzeit entfernt wurde. Umgekehrt ändert das Aktualisieren der deklarierten Action-Laufzeit nicht automatisch die Node-Version, mit der die Tests des Projekts laufen.

Deshalb kann ein Repository mehrere voneinander unabhängige Migrationsflächen enthalten:

  • JavaScript-Actions, die in eigenen action.yml-Dateien des Repositories deklariert sind.
  • Drittanbieter-Actions, auf die Workflow-Dateien verweisen.
  • Das gebündelte JavaScript unter dist/, sofern das Projekt kompilierten Output in Git eincheckt.
  • Versionen und Betriebssysteme der Self-Hosted-Runner.
  • Die eigene Node-Version des Projekts für Tests, Builds, CLIs oder Release-Skripte.

GitHubs frühere Abkündigung gab Maintainerinnen und Maintainer eine Übergangszeit und nannte den endgültigen Entfernungstermin. Node.js führt für Node 20 selbst den 24. März 2026 als Ende des Lebenszyklus auf. Die Änderung bei Actions entfernt damit einen Ausführungspfad, der ohnehin auf einer nicht mehr unterstützten Upstream-Laufzeit beruhte; es handelt sich nicht um eine neue Node.js-Release-Regel.

Die erste Prüfung: Herausfinden, was tatsächlich ausgeführt wird

Beginne mit den Workflow-Dateien, aber höre dort nicht auf. Suche sowohl nach direkter Action-Nutzung als auch nach Action-Definitionen. Ein sinnvoller erster Durchlauf in einem Repository umfasst:

.github/workflows/
action.yml
action.yaml
*/action.yml
*/action.yaml

Suche in Workflow-Dateien nach Referenzen wie uses: owner/project@vN. Ein Major-Version-Tag verrät nicht, welche Node-Laufzeit die referenzierte Version verwendet. Die Action muss am aufgelösten Tag oder Commit geprüft werden. Das ist besonders bei kleinen Community-Actions wichtig, die den Quellcode aktualisiert haben können, ohne ein neues Release zu veröffentlichen.

Bei einer Action, die im selben Repository gepflegt wird, solltest du action.yml prüfen und runs.using identifizieren. Steht dort node20, wird der Wert auf node24 geändert. Danach muss das gebündelte Ergebnis neu gebaut werden, wenn das Projekt erwartet, dass dist/ versioniert ist. Viele JavaScript-Actions führen kompilierte Dateien aus, nicht den TypeScript- oder JavaScript-Quellcode im Repository. Eine korrekte Änderung am Quellcode mit einem veralteten Bundle ist kein vollständiges Release.

Als Nächstes stellt sich die Frage, ob die Abhängigkeiten der Action Node 24 unterstützen. Node 24 ist nicht nur ein Etikett, das der Metadatenparser akzeptiert. Die Version bringt eine neuere V8-Engine und einen neueren Satz von Node-APIs mit. Dadurch können Annahmen über das Laden von Modulen, Package-Exports, OpenSSL-Verhalten sowie Datei- und Stream-APIs sichtbar werden. Das Risiko besteht nicht darin, dass jede Node-20-Action scheitert. Das Risiko besteht darin, dass ein Projekt sein tatsächliches Release-Artefakt nie unter der neuen Laufzeit ausgeführt hat.

Bei Drittanbieter-Actions solltest du ein von den Maintainerinnen und Maintainer veröffentlichtes Release bevorzugen, das Node-24-Unterstützung ausdrücklich dokumentiert. Ersetze nicht automatisch @v3 durch @v4, nur weil die Zahl höher ist. Lies die Release Notes, prüfe die Action-Metadaten und kläre, ob die neue Version andere Verhaltensänderungen einführt. Eine Laufzeitmigration ist kein guter Grund, einen Major-Versionswechsel ohne Prüfung von Inputs, Outputs, Berechtigungen und Sicherheitsverhalten zu übernehmen.

Warum die Updates der First-Party-Actions nützliche Beispiele sind

GitHubs eigene Actions zeigen konkret, wie die Migration umgesetzt wird. Das aktuelle Changelog von actions/checkout dokumentiert Node-24-Updates in der Release-Historie, und die aktuelle Dokumentation von actions/setup-node nennt neuere Action-Versionen, die Node 24 verwenden. Diese Projekte ändern nicht bloß ein Metadatenfeld: Sie veröffentlichen ein neues Release, aktualisieren die Dokumentation, führen ihre eigene Testmatrix aus und weisen auf Runner-Anforderungen sowie Verhaltensänderungen hin.

Dieses Muster lässt sich auch auf kleinere Repositories übertragen. Ein verantwortungsvolles Migrations-Release sollte vier Fragen klar beantworten: Welche Action-Version enthält die Änderung? Welche Runner-Version wird benötigt? Welche Betriebssysteme oder Architekturen werden nicht mehr unterstützt? Und haben sich Inputs oder Outputs geändert? Die Antworten gehören in die Release Notes, selbst wenn der Code-Diff klein ist.

Das Projekt actions/setup-node erinnert außerdem daran, dass sich eine Laufzeitmigration mit anderen Änderungen überschneiden kann. Die aktuelle Dokumentation beschreibt eine Node-24-basierte Action und enthält Hinweise zum Caching von Paketmanagern. Sie warnt, dass automatisches Caching nicht immer für Workflows mit erweiterten Berechtigungen oder vertraulichen Zugangsdaten geeignet ist. Diese Warnung wird nicht durch Node 24 verursacht, ist aber bei derselben Prüfung relevant, weil Maintainer Action-Versionen und Sicherheitseinstellungen von Workflows häufig gemeinsam aktualisieren.

Wer eine Action wegen Node-24-Unterstützung aktualisiert, übernimmt möglicherweise auch Änderungen an Cache-Standards, Authentifizierung, unterstützten Runner-Versionen oder der Erkennung von Paketmanagern. Die richtige Upgrade-Frage lautet daher nicht nur: „Lässt sich das YAML parsen?“, sondern: „Welcher Code wird jetzt mit welchen Berechtigungen und welchem gecachten Zustand ausgeführt?“

Self-Hosted-Runner sind die kritische Stelle

GitHubs Mitteilung nennt zwei Kompatibilitätsgrenzen für Node 24: macOS 13.4 und frühere Versionen sind inkompatibel, und ARM32 wird offiziell nicht unterstützt. Diese Grenzen sind für Open-Source-Projekte besonders relevant, weil deren Beitragende und Nutzer vielfältiger sind als die standardmäßige Matrix von GitHub-Hosted-Runnern. Ein Projekt kann einen grünen Ubuntu-Build haben, während Nutzer die Action auf einem älteren Intel-Mac, einem Raspberry-Pi-ähnlichen ARM32-Gerät oder einem privaten Runner hinter einer Firewall ausführen.

Das Betriebssystemproblem wird leicht übersehen, wenn der Workflow ein breites Label wie macos-latest verwendet. GitHub-Hosted-Labels verändern sich mit der Zeit, während ein Self-Hosted-Label meist eine Maschine bezeichnet, die eine Administratorin oder ein Administrator manuell aktualisieren muss. Ein Repository mit Unterstützung für Self-Hosted-Runner sollte eine minimale Runner-Version und einen unterstützten Betriebssystembereich dokumentieren, statt GitHubs Hosted-Images als vollständige Support-Politik zu behandeln.

Das Architekturproblem ist noch weniger sichtbar. ARM32-Maschinen kommen in gehosteter CI selten vor, daher testet eine Standardmatrix sie möglicherweise nie. Wenn das Projekt Actions lokal oder auf kleinen Edge-Geräten unterstützt, müssen die Maintainer entscheiden, ob ARM32 weiterhin unterstützt wird. Diese Entscheidung sollte ausdrücklich dokumentiert werden. „Die Action läuft unter Linux“ ist nicht präzise genug, wenn sich die Architekturunterstützung je nach Plattform unterscheidet.

Administratoren von Self-Hosted-Runnern sollten zunächst die Actions-Runner-Software aktualisieren, bevor sie Fehler in Actions untersuchen. Einige mit Node 24 kompatible Action-Releases verlangen einen ausreichend aktuellen Runner; die Release-Dokumentation der Action sollte für die minimale Version maßgeblich sein. Ein Runner-Update macht ein inkompatibles Betriebssystem nicht kompatibel, aber ein alter Runner kann irreführende Fehler erzeugen, bevor der Action-Code überhaupt erreicht wird.

Die sichere Reihenfolge besteht darin, das Runner-Upgrade schrittweise auszurollen, einen repräsentativen Workflow mit entfernten Secrets oder Testzugangsdaten auszuführen und anschließend Workflows mit Deployment-, Publishing- oder Release-Berechtigungen zu testen. Ein einfacher Unit-Test-Job reicht nicht, wenn die Action zusätzlich Artefakte hochlädt, Pakete signiert, Pull Requests öffnet oder ein OIDC-Token verwendet.

Das veröffentlichte Artefakt gehört zur Software

JavaScript-Actions committen ihr kompiliertes dist-Verzeichnis oft in Git, damit Nutzer während eines Workflow-Laufs keine Abhängigkeiten installieren oder die Action bauen müssen. Daraus entsteht eine typische Release-Falle: Das Repository kann eine moderne Quelldatei zeigen, während das von Nutzern verwendete Tag noch ein veraltetes Bundle enthält.

Maintainer sollten genau das Artefakt prüfen, das am Release-Ref ausgeführt wird. Dazu gehört die Bestätigung aller folgenden Punkte:

  1. action.yml oder action.yaml deklariert node24.
  2. Der Pfad unter main oder pre zeigt auf die erwartete generierte Datei.
  3. Die generierte Datei ist im veröffentlichten Tag vorhanden.
  4. Das Release wurde aus dem vorgesehenen Commit gebaut.
  5. Die Release Notes nennen das Tag oder den Commit, den Nutzer auswählen sollen.
  6. Der Test-Workflow führt das gebündelte Artefakt aus und nicht nur den Quellcode über einen Entwicklungs-Shortcut.

Projekte, die einen Release-Bot oder einen Build-Workflow verwenden, sollten prüfen, ob dieser Workflow selbst von einer alten Action abhängt. Eine Migration kann sich auf zirkuläre Weise blockieren: Der Maintainer aktualisiert die Action, aber der Release-Workflow verwendet weiterhin eine veraltete Checkout-, Setup-, Packaging- oder Publishing-Action. Aktualisiere die CI, mit der das Artefakt erzeugt wird, bevor du dich auf diese CI verlässt, um den aktuellen Stand des Artefakts zu beweisen.

Auch das Pinning ist hier wichtig. Ein veränderliches Major-Tag ist für Nutzer bequem, doch ein sicherheitsrelevanter Workflow kann eine Action auf einen vollständigen Commit-SHA pinnen und sie über einen geprüften Prozess aktualisieren. Wenn ein Projekt sowohl ein gut lesbares Tag als auch eine signierte oder digest-gepinnte Referenz veröffentlicht, sollten die Release Notes deren Zusammenhang erklären. Die Laufzeitmigration ist eine gute Gelegenheit, mehrdeutige Referenzen zu entfernen und zu dokumentieren, warum ein bestimmter Ref vertrauenswürdig ist.

Node-24-Unterstützung bedeutet nicht, dass das gesamte Projekt auf Node 24 laufen muss

In einem Repository mit einer Action gibt es zwei verschiedene Kompatibilitätsfragen. Die erste lautet, ob die Action von GitHubs Node-24-Laufzeit gestartet werden kann. Die zweite betrifft die Unterstützung von Node 24 durch die eigene Anwendung, Bibliothek, Testsuite oder das Kommandozeilenwerkzeug des Projekts. Für diese Bereiche können unterschiedliche Support-Regeln gelten.

Eine Action kann unter Node 24 laufen und dabei ein Projekt aufrufen, das weiterhin Node 18, 20 und 22 unterstützt. Die Laufzeit der Action ist ein Implementierungsdetail der Automatisierungsplattform; die Laufzeit, mit der die Software getestet wird, kann dagegen ein öffentliches Kompatibilitätsversprechen sein. Maintainer sollten die minimale Node-Version des Projekts nicht stillschweigend anheben, nur weil GitHub die Action-Laufzeit geändert hat.

Umgekehrt sollte ein Projekt, das in seiner Action-Implementierung Node-24-spezifische APIs verwendet, dies in der Dokumentation für Beitragende nennen. Entwicklerinnen und Entwickler, die lokal mit Node 20 testen, könnten sonst erst auf GitHub scheitern, wenn das gebündelte Artefakt ausgeführt wird. Eine kleine Laufzeitmatrix kann diese Lücke verhindern:

strategy:
  matrix:
    node: [22, 24]
steps:
  - uses: actions/checkout@v7
  - uses: actions/setup-node@v7
    with:
      node-version: ${{ matrix.node }}
  - run: npm ci
  - run: npm test

Diese Matrix ist ein Beispiel, keine allgemeingültige Empfehlung. Die Versionen sollten zur erklärten Support-Reichweite des Projekts passen. Wenn die Action selbst als gepacktes Artefakt getestet wird, sollte der Workflow sie außerdem über denselben Pfad aufrufen, den Nutzer verwenden, statt ausschließlich Quellmodule zu importieren.

Bei Projekten, die npm-Pakete veröffentlichen, ist die Migration auch eine Gelegenheit, die Paketmetadaten zu prüfen. engines.node sollte den unterstützten Bereich der Anwendung oder Bibliothek beschreiben und nicht einfach die Laufzeit der Action spiegeln. Lockfiles sollten versioniert werden. Abhängigkeitsupdates sollten getrennt von der Laufzeitmigration geprüft werden, damit sich ein Fehler der richtigen Änderung zuordnen lässt.

Lokale Emulatoren können das Problem verbergen

Werkzeuge, die GitHub-Actions-Workflows lokal ausführen, sind nützlich, bilden das Verhalten von GitHub-Hosted-Runnern aber nicht automatisch nach. Ein lokaler Emulator kann ein Container-Image mit Node 16 oder Node 20 auswählen, die gleiche Abbildung der Action-Laufzeit nicht implementieren oder eine andere Runner-Version verwenden. Ein erfolgreicher lokaler Lauf beweist daher nicht, dass das veröffentlichte Artefakt unter GitHubs Node-24-Laufzeit funktioniert.

Ein Problem im Projekt actions/checkout zeigt die Verwirrung: Ein lokales Ausführungswerkzeug kann ein altes Container-Image melden, obwohl das Action-Release Node 24 verwendet. Der Fehler liegt dann nicht unbedingt in der Action, sondern kann aus dem Laufzeitmodell des Emulators stammen. Maintainer sollten festhalten, welche Teile des Workflows lokal validiert werden und welche einen echten GitHub-Hosted-Runner oder einen korrekt konfigurierten Self-Hosted-Runner erfordern.

Ein praktischer Testplan nutzt beide Umgebungen gezielt. Schnelle Unit- und Integrationstests laufen lokal; anschließend wird ein minimierter echter Workflow gegen das gepackte Release der Action ausgeführt. Dieser reale Workflow sollte die wichtigen Inputs der Action abdecken, etwa private Repositories, große Dateien, Proxy-Einstellungen, Zugangsdaten, Pull-Request-Ereignisse oder generierte Outputs, sofern relevant. Lokales Testen bleibt für die Iteration wertvoll, sollte aber nicht als Ersatz für eine Validierung auf Plattformebene dargestellt werden.

Was Nutzer in ihren Workflows ändern sollten

Nutzer müssen normalerweise nicht jeden Workflow-Schritt neu schreiben. Priorität hat die Aktualisierung der Action-Referenzen auf Releases mit Node-24-Unterstützung. Danach werden verbleibende Fehler untersucht. Beginne mit den Actions, die für den Workflow besonders zentral sind: Checkout, Node-Setup, Caching, Artefakt-Upload und -Download, Sprach-Setup, Containeroperationen sowie Publishing-Actions.

Eine sichere Upgrade-Checkliste sieht so aus:

  • Release Notes lesen und Node-24-Unterstützung bestätigen.
  • Die dokumentierte minimale Runner-Version prüfen.
  • Berechtigungen, Secrets, Cache-Einstellungen und Änderungen an der Authentifizierung kontrollieren.
  • Pull Requests aus Forks getrennt von internen Pushes testen.
  • Den Workflow auf jedem tatsächlich unterstützten Betriebssystem und jeder unterstützten Architektur testen.
  • Die eigene node-version oder Versionsdatei des Projekts explizit beibehalten.
  • Release- und Publishing-Jobs mit einem Dry Run oder einem Staging-Ziel erneut ausführen.
  • Veraltete Node-20-Ausnahmevariablen entfernen; sie bieten keinen Fallback mehr.

Verwechsle actions/setup-node nicht mit der Laufzeit, die uses:-Actions verwenden. Dieser Workflow installiert Node 24 für Shell-Befehle:

- uses: actions/setup-node@v7
  with:
    node-version: 24
- run: npm test

Er repariert keine separate Drittanbieter-Action, deren Metadaten weiterhin using: node20 enthalten. Diese Action muss von ihren Maintainerinnen und Maintainer aktualisiert oder durch eine gepflegte Alternative ersetzt werden. Ist die Action aufgegeben und kann das Projekt das Risiko nicht akzeptieren, ungeprüften Code auszuführen, kann ein kleines lokales Skript sicherer sein als ein nicht verifiziertes Fork. Diese Entscheidung muss jedoch die Berechtigungen und den Datenfluss der Action berücksichtigen.

Nutzer sollten außerdem vermeiden, alle Action-Versionen gleichzeitig zu ändern. Werden Checkout, Setup-Node, Cache, Artefaktverarbeitung und eine Deployment-Action in einem Commit aktualisiert, lassen sich Fehler nur schwer isolieren. Eine gestaffelte Reihe kleiner Pull Requests schafft eine klarere Prüfspur und ermöglicht Rollbacks. Für ein Community-Projekt ist diese Klarheit auch für nachgelagerte Paketierer und Beitragende nützlich, die ältere Branches pflegen.

Was Maintainer in die Release Notes schreiben sollten

Eine Release Note mit dem Satz „Auf Node 24 migriert“ ist besser als Schweigen, aber Nutzer brauchen operative Details. Die Notiz sollte angeben, ob die Änderung die Action-Laufzeit, die ProjekLaufzeit oder beides betrifft. Sie sollte das erste Release mit der Änderung nennen und erklären, ob Nutzer ihre Workflow-Referenzen ändern müssen.

Bekannte Grenzen gehören ebenfalls hinein. GitHubs Hinweis macht beispielsweise deutlich, dass macOS 13.4 und frühere Versionen sowie ARM32 für Node-24-basierte JavaScript-Actions nicht mehr unterstützt werden. Gibt es eine projektspezifische Einschränkung, etwa eine native Abhängigkeit, eine minimale Runner-Version oder eine Voraussetzung für eine neuere npm-Version, gehört sie in dieselbe Release Note.

Maintainer sollten dokumentieren, wie sich die Migration überprüfen lässt. Ein kurzer Befehl zur Inspektion der Action-Metadaten, ein Link zur CI-Matrix und die Aussage, dass das gebündelte dist-Artefakt getestet wurde, helfen mehr als eine lange Liste von Dependency-Bumps. Wenn ein stabiler Branch die Migration nicht erhält, sollte das offen gesagt und das letzte unterstützte Action-Release angegeben werden.

Dies ist auch ein geeigneter Zeitpunkt für eine Support-Policy. Open-Source-Nutzer schließen häufig aus dem, was zufällig in der öffentlichen CI erfolgreich ist, auf den Support. Eine Tabelle oder ein Absatz, der GitHub-Hosted-Runner, Self-Hosted-Runner, lokale Emulatoren, Betriebssysteme und Architekturen trennt, verhindert dieses unbeabsichtigte Versprechen. Nutzer können vor dem Upgrade entscheiden, ob es für sie passt, statt dass erst die Deployment-Pipeline die Grenze entdeckt.

Sicherheits- und Supply-Chain-Auswirkungen

Die Entfernung von Node 20 ist ein Kompatibilitätsereignis, aber Action-Upgrades sind zugleich Supply-Chain-Änderungen. Eine Action läuft im Kontext eines Workflows, der Repository-Inhalte, Tokens, Cloud-Zugangsdaten, Signaturmaterial oder Zugriff auf Deployment-Systeme enthalten kann. Ein neues Release sollte genauso geprüft werden wie jede andere Abhängigkeit, die mit diesen Privilegien ausgeführt wird.

Prüfe den Diff zwischen den alten und neuen Action-Refs, nicht nur die Überschrift des Releases. Kontrolliere Änderungen an Berechtigungen, Shell-Befehlen, Netzwerkendpunkten, Artefaktverarbeitung und Aufräumarbeiten nach dem Job. Bei Actions, die nicht vertrauenswürdige Pull Requests verarbeiten, sollte geprüft werden, ob das neue Release den Zeitpunkt des Checkouts oder der Bereitstellung von Zugangsdaten verändert. Die Laufzeitmigration darf kein Grund sein, diese Kontrollen auszulassen.

Caching verdient besondere Aufmerksamkeit. Ein Cache kann die Geschwindigkeit erhöhen, doch ein Workflow, der Abhängigkeitsdaten wiederherstellt, bevor nicht vertrauenswürdige Eingaben verarbeitet werden, kann einen Weg für Cache-Poisoning oder den Zugriff auf Zugangsdaten eröffnen. Die aktuelle setup-node-Dokumentation empfiehlt, automatisches Paketmanager-Caching zu deaktivieren, wenn es in Workflows mit erweiterten Berechtigungen oder vertraulichen Informationen nicht benötigt wird. Diese Empfehlung geht über Node 24 hinaus, ist aber unmittelbar relevant, wenn ein Action-Upgrade das Cache-Verhalten verändert.

Das Pinning von Action-Referenzen auf geprüfte Commit-SHAs kann das Risiko unerwarteter Tag-Verschiebungen reduzieren, verursacht aber zusätzlichen Pflegeaufwand. Projekte, die Dependabot, Renovate oder ein anderes Update-System nutzen, sollten sicherstellen, dass das Werkzeug die Laufzeitmigration versteht und nicht immer wieder dieselbe veraltete Major-Version öffnet. Ein signiertes Release, Provenance-Metadaten und ein reproduzierbarer Build sind nützliche Ergänzungen. Nichts davon ersetzt jedoch die Prüfung des Codes, der mit Secrets ausgeführt wird.

Alternativen, wenn eine Action noch nicht migriert ist

Für eine nicht gepflegte Action gibt es keinen universellen Ersatz. Die richtige Entscheidung hängt davon ab, was sie tut, welche Berechtigungen sie benötigt und ob ihr Verhalten für das Projekt unverzichtbar ist. Meist stehen vier Wege offen.

Erstens kann der Maintainer um ein Node-24-Release gebeten werden; bei einem aktiven Projekt lässt sich die Migration gegebenenfalls beitragen. Ein Pull Request sollte das gebaute Artefakt, Tests gegen die unterstützte Runner-Matrix und die Release-Dokumentation enthalten. Nur runs.using zu aktualisieren, ohne das Bundle zu testen, ist unvollständig.

Zweitens kann die Action durch ein gepflegtes Projekt mit klarer Release- und Support-Policy ersetzt werden. Vergleiche Verhalten und Berechtigungen, nicht nur Funktionsnamen. Eine Action mit weniger Sternen, aber transparenter Pflege und einem engen Berechtigungsmodell kann besser passen als eine populäre Action mit undurchsichtigem Release-Prozess.

Drittens kann ein kleiner Teil der Logik in gewöhnliche Workflow-Schritte oder ein Repository-Skript verschoben werden. Das verringert möglicherweise die Abhängigkeit von einer Action-Laufzeit, macht den Code aber nicht automatisch sicherer. Auch Shell-Skripte laufen mit Workflow-Berechtigungen, müssen Eingaben validieren, Daten korrekt quoten und dürfen Secrets nicht offenlegen.

Viertens kann die alte Action in einem eigenen Job oder Repository isoliert werden, während die Migration vorbereitet wird. Das ist eine Eindämmungsmaßnahme, keine dauerhafte Lösung. Berechtigungen sollten begrenzt, Deployment-Zugangsdaten nicht übergeben und Outputs explizit gemacht werden. Das Projekt sollte den vorläufigen Charakter nennen, damit nachgelagerte Nutzer die Konstruktion nicht für dauerhaften Support halten.

Ein Fork kann angemessen sein, wenn das ursprüngliche Projekt aufgegeben wurde und der Code klein genug für ein Audit ist. Er kann jedoch langfristige Wartungsschulden erzeugen. Der Fork sollte seine Beziehung zum Upstream dokumentieren, Lizenzhinweise erhalten, eigene Releases veröffentlichen und erklären, wie Nutzer das generierte Artefakt prüfen können. Ein umbenanntes Tag ohne Release-Prozess verschiebt die Unsicherheit nur.

Die größere Lehre für Open-Source-Automatisierung

Plattformverwaltete Laufzeiten erinnern daran, dass eine Open-Source-Action zwei Wartungsverträge hat. Der erste gilt für das Quellcode-Ökosystem: Abhängigkeiten, Compiler, Paketmanager und Sprachversionen. Der zweite gilt für die Automatisierungsplattform: Runner-Versionen, unterstützte Betriebssysteme, Ausführungssemantik, Berechtigungen und Artefaktkonventionen. Ein Projekt kann den einen Vertrag erfüllen und am anderen scheitern.

Die Node-24-Migration legt außerdem eine wiederkehrende Schwäche von Open-Source-Infrastruktur offen: Nutzer entdecken die Support-Policy häufig erst durch einen fehlgeschlagenen Job. Das ist vermeidbar. Repositories können eine getestete Matrix veröffentlichen, das Release-Artefakt sichtbar halten, minimale Runner-Versionen nennen und einen geplanten Job ergänzen, der bevorstehende Laufzeitänderungen testet, bevor die Plattform sie verbindlich macht.

Die Laufzeit einer Action sollte als Produktoberfläche getestet werden. Sie verdient Release Notes, Kompatibilitätstests, eine Sicherheitsprüfung und einen Rollback-Plan. Der Quellcode ist nur ein Teil dessen, was Nutzer installieren; Metadaten, generiertes Bundle, Tag, Runner und Berechtigungen bilden zusammen die tatsächliche Software.

Für Nutzer besteht die unmittelbare Aufgabe darin, unterstützte Action-Releases zu aktualisieren und die wichtigen Umgebungen zu verifizieren. Für Maintainer ist die wichtigere Aufgabe, die nächste Migration unspektakulär zu machen. Dazu gehören eine veröffentlichte Support-Policy, ausdrückliche Runner-Anforderungen, ein reproduzierbares Release-Artefakt und CI, die den von Nutzern ausgeführten Pfad testet. Node 24 ist die neue Grundlage in GitHub Actions. Die Qualität der Migration zeigt sich weniger daran, ob sich eine YAML-Datei geändert hat, als daran, ob Beitragende die neue Grenze verstehen können, bevor sie die Produktion erreicht.

Quellen und weiterführende Lektüre