Build-Caching in CI: Schlüssel, Restore-Fallbacks und Cache-Vergiftung

Ziel

Pipeline-Zeit verkürzen, indem heruntergeladene Abhängigkeiten und Image-Layer wiederverwendet werden, ohne dass der Cache Build-Ergebnisse verändert oder zu einem Weg für das Einschleusen von Code wird.

Voraussetzungen

Lockfile-Dateien für jeden Paketmanager im Repository; ein Dockerfile, dessen Reihenfolge die Installation von Abhängigkeiten vor das Kopieren des Quellcodes stellt; ein CI-System mit einer Cache-Aktion oder eine vom Builder erreichbare Registry.

Schritte

1. Abhängigkeits-Caches über das Betriebssystem plus einen Hash der Lockfile-Datei schlüsseln (${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}) und restore-keys vom spezifischsten zum allgemeinsten auflisten, damit eine Änderung der Lockfile-Datei den nächstgelegenen älteren Cache wiederherstellt, statt kalt zu starten. Die zitierte GitHub-Referenz beschreibt zuerst die exakte Übereinstimmung, dann Teilübereinstimmungen, dann die Restore-Keys der Reihe nach.
2. Den Gültigkeitsbereich verstehen: Dieselbe Referenz hält fest, dass ein Lauf Caches vom eigenen Branch oder vom Default-Branch (sowie vom Basis-Branch bei Pull Requests) wiederherstellen kann, nie von Geschwister- oder Kind-Branches. Den Cache des Default-Branch beim Merge aufwärmen, damit Feature-Branches ihn erben.
3. Das Download-Verzeichnis des Paketmanagers cachen statt des installierten Baums, ausser die Installation ist eine reine Funktion der Lockfile-Datei.
4. Bei Images den BuildKit-Cache ausdrücklich exportieren: Die zitierte Seite zu den Backends merkt an, dass im Unterschied zum stets aktiven lokalen Cache externe Backends mit --cache-to exportiert und mit --cache-from importiert werden müssen; type=registry mit mode=max verwenden, um Zwischenstufen zu behalten, und sowohl den Branch-Cache als auch den Main-Cache importieren.
5. Dockerfile-Anweisungen von selten zu häufig geändert ordnen, wie es die zitierte Seite zur Invalidierung empfiehlt, denn die Invalidierung eines Layers invalidiert alles danach; die Seite hält zudem fest, dass COPY-Prüfsummen mtime ignorieren.
6. Nie Secrets oder Tokens in gecachte Pfade schreiben: Die GitHub-Referenz hält fest, dass Cache-Inhalte weder signiert noch verifiziert werden und dass jeder, der einen Pull Request eröffnen kann, Caches des Basis-Branch lesen kann. Cache-Schreibzugriff auf vertrauenswürdige Auslöser beschränken (push, schedule) und Workflows mit nicht vertrauenswürdigen Auslösern nur lesend belassen.
7. Auf die Räumung achten: Die Referenz nennt einen Standardwert von 10 GB pro Repository und die Entfernung von Einträgen, auf die 7 Tage lang nicht zugegriffen wurde; übergrosse Caches thrashen.
8. Regelmässig ohne Cache neu bauen (--no-cache oder ein Schlüssel mit Datumsanteil), um Abhängigkeitsdrift zu erkennen, die ein warmer Cache verdeckt.

Erwartetes Ergebnis

Ein Cache-Treffer bei unveränderten Lockfile-Dateien; ein naher Treffer nach einer kleinen Änderung der Lockfile-Datei; identische Build-Ausgaben mit oder ohne Cache; kein Pfad im Cache, den ein Pull Request aus einem Fork für einen privilegierten Lauf vergiften kann.

Grenzen und Prüfbasis

Der Nutzen des Caches hängt vom Verhältnis von Netzwerkgeschwindigkeit zu Installationszeit ab und wird nicht als Zahl behauptet. Die Mechanik folgt der zitierten GitHub- und Docker-Dokumentation; andere CI-Systeme grenzen den Gültigkeitsbereich ab und räumen anders.