GitHub Actions cache-mode: Cache-Berechtigungen hinter dem grünen CI-Status überprüfen
Wenn ein CI-Lauf grün abgeschlossen wird, beim nächsten Durchlauf aber Abhängigkeiten erneut heruntergeladen werden, neigt man schnell dazu, den Cache-Schlüssel anzupassen. Künftig sollte jedoch auch geprüft werden, ob das Speichern aufgrund fehlender Berechtigungen übersprungen wurde. Allein aus der Tatsache, dass ein Workflow erfolgreich war, lässt sich nicht ableiten, dass auch ein Cache erstellt wurde.
GitHub hat am 10. September 2026 die allgemeine Verfügbarkeit von cache-mode angekündigt. In allen Plänen auf github.com lässt sich der Cache-Zugriff nun auf Workflow- oder Job-Ebene festlegen. Aufbauend auf einem früheren Artikel über die bisherigen schreibgeschützten Standardwerte liegt der Schwerpunkt diesmal auf expliziten Konfigurationen und Verifizierungsmethoden.
Bestätigte Funktionen: Vier Kombinationen aus Wiederherstellung und Speicherung
read erlaubt nur die Wiederherstellung, während write sowohl die Wiederherstellung als auch das Speichern ermöglicht. write-only gestattet ausschließlich das Speichern und none blockiert beides. Der erste wichtige Prüfschritt besteht darin, den Namen write nicht fälschlicherweise als reine Speicheroption misszuverstehen.
Ein auf Job-Ebene deklarierter Wert hat Vorrang vor workflowweiten Einstellungen. Beim Aufruf wiederverwendbarer Workflows können jedoch keine weitergehenden Zugriffsrechte erlangt werden, als der Aufrufer gewährt hat. Beurteilen Sie die tatsächlichen Berechtigungen einer gesamten Ausführung daher nicht allein anhand der Deklaration in einer einzelnen Datei.
Auch ein grüner Lauf ist kein Beweis für eine erfolgreiche Speicherung
Die offizielle Dokumentation erläutert, dass unzulässige Cache-Operationen eine Hinweismeldung im Protokoll hinterlassen und der Prozess fortgesetzt wird. Eine blockierte Wiederherstellung wird als Cache-Miss behandelt und ein blockiertes Speichern wird schlicht nicht ausgeführt. Dass der Workflow selbst nicht fehlschlägt, ist der entscheidende Aspekt für die Fehleranalyse.
Daher ist es ratsam, in den Betriebsprotokollen zwischen dem Erfolg der Ausführung und dem Cache-Ergebnis zu unterscheiden. Überprüfen Sie für jeden Lauf, welches Ereignis ihn ausgelöst hat, welcher Modus angewendet wurde, ob eine Wiederherstellung stattfand und ob das Speichern übersprungen wurde. Dies ist eine empfohlene Betriebspraxis auf Basis der offiziellen Funktionsbeschreibung und keine automatisch bereitgestellte neue Dashboard-Funktion.
Vor der Implementierung eine kompakte Berechtigungsübersicht erstellen
Gehen Sie die tatsächlichen Workflows Ihres Repositories durch und identifizieren Sie Jobs, die Caches erzeugen, sowie solche, die sie nutzen. Jobs, die Abhängigkeiten auf vertrauenswürdigen Branches vorbereiten, externe Änderungen testen oder Deployment-Artefakte validieren, müssen nicht mit denselben Berechtigungen versehen werden.
Beantworten Sie für jeden Job zwei Fragen: Muss dieser Job einen bestehenden Cache lesen? Darf das Ergebnis dieses Jobs gespeichert werden, damit spätere Ausführungen darauf zugreifen können? Wenn beides nicht erforderlich ist, lohnt es sich, den gewohnheitsmäßigen Einsatz von Caches zu hinterfragen. Die tatsächliche Konfiguration muss sich jedoch stets an den Vertrauensgrenzen und der Build-Struktur Ihres Repositories orientieren.
Minimales Experiment: Ein reiner Lese-Job
Geben Sie beispielsweise auf oberster Ebene eines Test-Workflows cache-mode: read an und stellen Sie sicher, dass keine jobspezifischen Überschreibungen vorliegen. Vergleichen Sie anschließend, ob die Testergebnisse mit Cache mit denen ohne Cache übereinstimmen. Da Caches lediglich ein Hilfsmittel zur Reduzierung der Ausführungszeit sein sollten, müssen zunächst die Annahmen im Build-Prozess hinterfragt werden, falls das Fehlen eines Caches die Korrektheit beeinträchtigt.
Das Kriterium für das Bestehen dieses Experiments ist nicht bloß eine grüne CI-Statuszeile. Sie sollten in der Lage sein, den Wiederherstellungsversuch und das Auslassen des Speicherns nachzuvollziehen und das Ergebnis bei einer nachfolgenden Ausführung mit denselben Eingaben zu verifizieren. Wenn Sie Commits vor und nach dem Experiment, Trigger, wirksame Konfigurationen und die entsprechenden Log-Stellen dokumentieren, können auch Teammitglieder diese Bewertung problemlos nachvollziehen.
Bei wiederverwendbaren Workflows den gesamten Aufrufpfad prüfen
Selbst wenn in einem gemeinsamen Workflow sichere Standardwerte hinterlegt sind, müssen die aufrufende Seite und die individuellen Job-Einstellungen gemeinsam geprüft werden. Dass verschiedene Repositories dieselbe Datei aufrufen, bedeutet nicht zwingend, dass sie auch mit denselben Berechtigungen ausgeführt wird.
Verfolgen Sie bei einem Review den Pfad ausgehend vom Aufrufer über die Cache-Deklaration des Jobs bis hin zum aufgerufenen Workflow. Weichen die erwarteten Berechtigungen von den tatsächlichen Protokollen ab, sollten Sie die Ursache der Konfiguration ermitteln, anstatt den Cache-Schlüssel unnötig zu verkomplizieren. Dies ist ein Ansatz zur Reduzierung von Diagnosezeiten in Organisationen mit hohem Wiederverwendungsgrad und stellt keine messbare Leistungssteigerung dar.
Wichtige Ausnahmen und empfohlene Reihenfolge der Einführung
Wenn bei Ereignissen mit geringerem Vertrauensniveau wie pull_request_target explizit write oder write-only festgelegt wird, kann dies die schreibgeschützte Standardbeschränkung außer Kraft setzen und das Risiko einer Cache-Vergiftung (Cache Poisoning) erhöhen. GitHub fügt in einem solchen Fall einen Warnhinweis hinzu. Es sollte vermieden werden, Schreibberechtigungen auszuweiten, nur um eine solche Warnung zum Verschwinden zu bringen.
Umgekehrt ist auch die Entscheidung, sämtliche Caches zu blockieren, mit Kosten verbunden. Da sich Download- und Build-Zeiten verlängern können, empfiehlt es sich, die Ausführungszeiten zunächst anhand eines repräsentativen Jobs direkt zu vergleichen, bevor der Umfang ausgeweitet wird. Versprechen Sie keine Leistungssteigerungen auf Basis bloßer Schätzungen; legen Sie stattdessen im Team gemeinsam fest, welche Einschränkungen aus Sicherheitsgründen notwendig sind und welche Verzögerungen in Kauf genommen werden können.
Fragen, die Ihr Team jetzt klären sollte
Die heutige Aufgabe besteht nicht darin, die neue Konfiguration pauschal auf alle Repositories anzuwenden. Identifizieren Sie stattdessen in einem einzelnen, kritischen Workflow die Cache-Produzenten und -Konsumenten, dokumentieren Sie deren Berechtigungen und überprüfen Sie in einem Testlauf die Nachweise für Wiederherstellung und Speicherung. Handelt es sich um Deployment-Jobs, sollten die Änderungen klein gehalten werden, damit die Verantwortlichen die Protokolle prüfen und mit den Erwartungen abgleichen können.
In der Praxis stellt sich häufig die Frage, warum ein CI-Lauf erfolgreich ist, obwohl der Speicherschritt übersprungen wurde. Dieser Artikel erklärt diese Unklarheit anhand des offiziellen Verhaltens und stützt sich nicht auf externe Community-Umfragen oder allgemeine Ausfallstatistiken. Wenn Sie bei der Einführung neuer Funktionen die Leistungsauswirkungen und Berechtigungsergebnisse separat betrachten, lassen sich künftige Cache-Probleme deutlich präziser diagnostizieren.