Actions-Lockfiles sind allgemein verfügbar: Was ein grüner Check belegt
Eine PR kann dieselbe uses-Version zeigen, obwohl sich der dahinterliegende Code ändert. Tags können auf andere Commits verschoben werden. GitHub hat Workflow-Lockfiles am 28. Oktober allgemein verfügbar gemacht. Nach der Vorschau lohnt deshalb die Frage, welche Belege die einzelnen Prüfungen liefern.
Lesbare Referenzen und feste Commits
.github/workflows/actions.lock verbindet Action-Referenzen mit den auszuführenden Commits. Die Datei wird mit gh actions-lock erzeugt. Unterstützt werden Free, Team und GitHub Enterprise Cloud einschließlich Datenresidenz. Workflows lassen sich einzeln aufnehmen; generierte Datei und Workflow-Änderungen werden gemeinsam geprüft, statt die Datei von Hand aufzubauen.
Ein fiktives demo/build@v1 zeigt zunächst auf Commit A und später auf B. Ohne Fixierung kann beim nächsten Lauf anderer Code ausgewählt werden. Das Lockfile hält den gespeicherten Commit fest. Die Grafik ist ein eigenes Beispiel, kein echter Testlauf. Ist der Commit vom gespeicherten Upstream-Tag oder -Branch nicht mehr erreichbar, kann der Lauf ihn ablehnen.
Was bestätigt eine Offline-Prüfung?
gh actions-lock --verify-local prüft ohne Netzwerk nur die Abdeckung: Gibt es für uses-Referenzen Einträge? Das eignet sich vor einem Commit, bestätigt aber keine Herkunft. gh actions-lock --verify prüft diese online; der Runner prüft erneut beim Jobstart. Ein grünes Ergebnis hat deshalb jeweils eine andere Aussage.
Wird in einer parallelen PR eine Action ergänzt und der Eintrag vergessen, kann die lokale Prüfung die Lücke erkennen. Vollständige Einträge beweisen weder Herkunft noch sicheren Code. Die zweite Grafik fasst dokumentierte Prüfbereiche zusammen. Für diesen Artikel wurde die CLI nicht installiert oder ausgeführt.
Wiederverwendbare Workflows haben eine eigene Grenze
Transitive Action-Abhängigkeiten sind erfasst. Aufrufe wiederverwendbarer Workflows über jobs.<job_id>.uses werden dagegen nicht vom Lockfile fixiert; dafür ist ein vollständiger Commit-SHA nötig. Deren interne Actions gehören zum Lockfile des definierenden Repositorys, nicht zu dem des Aufrufers.
Ruft ein App-Repository einen Deployment-Workflow aus einem Plattform-Repository auf, genügt die Prüfung des App-Lockfiles nicht. Aufruf-SHA und Abhängigkeiten auf der Plattformseite gehören zusammen. Runner-Image, Eingaben und Secrets bleiben zusätzliche Build-Eingaben: Ein fester Action-Commit friert nicht die gesamte Umgebung ein.
Versionsänderung und Lockfile gemeinsam lesen
Dependabot regeneriert bei Versionsupdates aufgenommener Actions den passenden Lockfile-Eintrag in derselben PR. So lassen sich Version und tatsächlicher Commit vergleichen. --relock aktualisiert verschobene Referenzen und schreibt Dateien; es ist keine rein lesende Prüfung. Die Codeprüfung bleibt notwendig.
Require lockfile kann die Einführung erzwingen, beseitigt aber keine Repository-Grenzen. Ein einzelner Workflow ist ein guter Einstieg, um Erzeugung, Review und Online-Prüfung zu verstehen. Beim nächsten grünen Check lohnt die genaue Frage: Belegt er Abdeckung, Herkunft oder eine menschliche Prüfung des ausgewählten Codes?