GitHub-Actions-Lockfiles für Workflows sind allgemein verfügbar und fixieren genaue Commits

GitHub hat am 28. Oktober 2026 die allgemeine Verfügbarkeit von Lockfiles für Abhängigkeiten in GitHub-Actions-Workflows angekündigt. Sie stehen in GitHub Enterprise Cloud, in GitHub Enterprise Cloud mit Datenresidenz sowie in den Tarifen Team und Free bereit. Ein Lockfile erlaubt einem Workflow, lesbare Verweise auf Tags und Branches zu behalten und trotzdem genau die gesperrten Commits auszuführen, selbst wenn sich diese Verweise später verschieben. Der Changelog-Eintrag sagt, die allgemeine Version bringe die Fähigkeiten aus der öffentlichen Vorschau.

Das Problem sind veränderbare Verweise. Ein Workflow, der eine Action unter einem Tag oder Branch nutzt, führt den Commit aus, auf den dieser Name beim Start des Jobs zeigt. Verschiebt sich der Name, läuft unbemerkt anderer Code. Das Lockfile hält die Commits hinter diesen Namen fest, für die Actions und für ihre transitiven Abhängigkeiten, also die Actions, die diese Actions ihrerseits nutzen. Die Erweiterung gh actions-lock der GitHub-CLI erzeugt die Datei .github/workflows/actions.lock. Die Workflow-Datei behält ihre lesbaren Verweise, und das Lockfile bestimmt, was tatsächlich läuft.

Die Einführung kann schrittweise erfolgen. Teams nehmen Workflows einzeln auf. Ist ein Workflow aufgenommen, verlangt GitHub Actions, dass jede seiner Abhängigkeiten im Lockfile steht, und führt den aufgezeichneten Commit aus. Die Einführung muss also nicht alle Workflows auf einmal erfassen. Für eine feste Regel können Administratoren auf Unternehmens-, Organisations- und Repository-Ebene die Richtlinie „Lockfile verlangen“ nutzen. Der Eintrag beschreibt nicht, was mit Workflows geschieht, die gegen die Richtlinie verstoßen; Administratoren sollten sie zuerst in kleinem Umfang testen.

Zwei Funktionen halten die Datei aktuell. Wenn Dependabot ein Versionsupdate für eine Action in einem aufgenommenen Workflow öffnet, erzeugt es den passenden Lockfile-Eintrag im selben Pull Request neu, ohne zusätzliche Konfiguration. Das spart einen eigenen Schritt zur Neuerzeugung. Außerdem lassen sich veraltete Lockfiles prüfen. Die Prüfung stellt fest, ob das Lockfile aktuell ist, ohne Dateien zu ändern; sie kann daher als CI-Prüfung laufen und einen Build scheitern lassen, wenn jemand einen Workflow ändert, aber das Lockfile vergisst.

GitHub benennt die Grenze klar. Lockfiles helfen gegen unerwartete Änderungen bei Abhängigkeiten, entscheiden aber nicht, ob eine Abhängigkeit sicher ist. Ein Commit, der beim Sperren bösartig oder verwundbar war, bleibt es. GitHub rät, Abhängigkeiten vor dem Sperren zu prüfen. Das Lockfile verlegt den Prüfzeitpunkt also nach vorn, auf das Sperren und jedes Dependabot-Update, und ersetzt die Prüfung nicht. Der Eintrag sagt auch nichts zu selbst gehosteten Runnern oder GitHub Enterprise Server; betroffene Teams sollten die Dokumentation lesen.

Zum Start installiert man die Erweiterung aus dem Repository gh-actions-lock, erzeugt das Lockfile und prüft und committet dann das Lockfile und die Workflow-Änderungen. GitHub verweist auf seine Dokumentation sowie auf eine Community-Diskussion und einen Issue-Tracker für Rückmeldungen.

Für Teams, die auf Actions von Dritten bauen, liegt der praktische Gewinn in einem prüfbaren Nachweis, welchen Code eine Pipeline genau ausgeführt hat, und in einer Möglichkeit, Abweichungen in einem Pull Request sichtbar zu machen.