Abhängigkeiten für schnellere Builds cachen

Die meiste CI-Zeit entfällt darauf, bei jedem Lauf dieselben Abhängigkeiten herunterzuladen und zu installieren. Durch Caching werden sie zwischen Läufen gespeichert, sodass nachfolgende Builds die bereits geleistete Arbeit wiederverwenden können. Dadurch verkürzt sich die Pipeline oft deutlich.

GitHub stellt actions/cache bereit. Sie geben einen zu cachenden Pfad und einen Schlüssel an, der den Cache-Eintrag identifiziert. Bei einem Treffer wird der Pfad wiederhergestellt; andernfalls wird er nach Abschluss des Jobs gespeichert.

Der Schlüssel sollte sich nur ändern, wenn sich auch der gecachte Inhalt ändern soll. Das Hashing des Lockfiles ist ideal: Ein neues Lockfile bedeutet neue Abhängigkeiten, daher wird ein neuer Cache-Eintrag erstellt.

restore-keys stellt Präfixe als Fallback bereit. Wenn der exakte Schlüssel nicht gefunden wird, stellt die Action den neuesten Cache wieder her, dessen Schlüssel mit einem Präfix beginnt. So erhalten Sie einen teilweise aufgewärmten Start.

Bei einer exakten Übereinstimmung des Schlüssels erhalten Sie einen Cache-Treffer und der Pfad wird wiederhergestellt. Bei einem Miss läuft der Job normal weiter und der Cache wird am Ende unter dem primären Schlüssel gespeichert, sodass er beim nächsten Mal bereitsteht.

Die Setup-Actions für Programmiersprachen verfügen über integriertes Caching. Für Node übernimmt setup-node mit cache: npm den Dependency-Cache für Sie, sodass kein separater Cache-Schritt erforderlich ist.

Cache-Verzeichnisse des Paketmanagers statt, sofern möglich, der installierten node_modules. Download-Caches sind portabel und der Installationsschritt überprüft weiterhin die Integrität.

• Node: ~/.npm
• Python: pip-Cache
• Java: ~/.m2 oder Gradle-Caches

Caches gelten für einen Branch, mit einem Fallback auf den Standardbranch, und unterliegen einem Größenlimit pro Repository. Nicht verwendete Caches werden mit der Zeit entfernt. Entwerfen Sie daher Schlüssel, die sich sauber ändern.

Wenn sich Ihr Schlüssel niemals ändert, können Sie veraltete Abhängigkeiten ausliefern. Verknüpfen Sie den Schlüssel immer mit dem Hash des Lockfiles, damit Aktualisierungen den Cache automatisch ungültig machen.

Fügen Sie bei Matrix-Builds über mehrere Betriebssysteme oder Versionen runner.os und die Version in den Schlüssel ein, damit jede Variante ihren eigenen korrekten Cache erhält und es nicht zu Konflikten kommt.

Vergleichen Sie die Jobdauer vor und nach dem Caching und beobachten Sie die Anzeige für Cache-Treffer in den Logs. Eine dauerhaft niedrige Trefferquote weist darauf hin, dass sich ein Schlüssel zu häufig ändert.

Testen Sie Ihr Verständnis des Cachings von Abhängigkeiten.

Sie haben Ihre CI mit Dependency-Caching beschleunigt: mit der Action actions/cache, einem Schlüssel auf Basis des Lockfile-Hashs und dem Fallback über restore-keys, mit integriertem Caching in Setup-Actions, der Auswahl geeigneter Cache-Inhalte, der Aufnahme von Betriebssystem und Version in Matrix-Schlüssel sowie der Vermeidung veralteter Caches durch die Verknüpfung des Schlüssels mit dem Lockfile.