Informationen zum Zwischenspeichern von Workflow-Abhängigkeiten
Workflow-Läufe verwenden häufig dieselben Ausgaben oder heruntergeladenen Abhängigkeiten in aufeinanderfolgenden Durchläufen. Tools zur Verwaltung von Paketen und Abhängigkeiten wie beispielsweise Maven, Gradle, npm und Yarn halten einen lokalen Cache mit heruntergeladenen Abhängigkeiten.
Um die Zeit zum Neuerstellen von Dateien wie Abhängigkeiten einzusparen, kann GitHub in Workflows häufig verwendete Dateien zwischenspeichern.
Um Abhängigkeiten für einen Auftrag zwischenzuspeichern, kannst du die cache
-Aktion von GitHub verwenden. Die Aktion erstellt einen Cache, der durch einen eindeutigen Schlüssel identifiziert wird, und stellt diesen wieder her. Wenn du die unten aufgeführten Paket-Manager zwischenspeicherst, erfordert die Verwendung ihrer jeweiligen Setup-*-Aktionen minimale Konfiguration und erstellt Abhängigkeitscaches für dich und stellt diese wieder her.
Paket-Manager | Setup-*-Aktion zum Zwischenspeichern |
---|---|
npm, Yarn, pnpm | setup-node |
pip, pipenv, Poetry | setup-python |
Gradle, Maven | setup-java |
RubyGems | setup-ruby |
Go go.sum | setup-go |
.NET NuGet | DotNet-Setup |
Warnung: Es wird empfohlen, keine vertraulichen Informationen im Cache zu speichern. Sensible Informationen umfassen beispielsweise Zugriffstoken oder Anmeldedaten, die in einer Datei im Cache-Pfad gespeichert sind. Auch Befehlszeilenprogramme (CLI) wie docker login
können Anmeldeinformationen in einer Konfigurationsdatei speichern. Jeder Benutzer mit Lesezugriff kann einen Pull-Request für ein Repository erstellen und auf den Inhalt des Caches zugreifen. Forks eines Repositorys können auch Pull-Requests auf den base branch (Basiszweig) erstellen und auf Caches im Basiszweig zugreifen.
Vergleich: Artefakte v/s Zwischenspeicherung von Abhängigkeiten
Artefakte und Caching sind ähnlich, da sie die Möglichkeit bieten, Dateien auf GitHub zu speichern, aber die beiden Funktionalitäten bieten verschiedene Anwendungsfälle und dürfen nicht miteinander verwechselt werden.
- Verwende die Zwischenspeicherung, wenn du Dateien wiederverwenden möchtest, die sich zwischen Aufträgen oder Workflowausführungen nur selten verändern, zum Beispiel Buildabhängigkeiten aus einem Paketverwaltungssystem.
- Verwende Artefakte, wenn du von einem Auftrag generierte Dateien speichern möchtest, um diese nach einer Workflowausführung zu öffnen, zum Beispiel Binärdateien oder Buildprotokolle.
Weitere Informationen zu Artefakten von Workflowausführungen findest du unter Speichern und Freigeben von Daten aus einem Workflow.
Einschränkungen für den Zugriff auf einen Cache
Zugriffsbeschränkungen bieten Cache-Isolation und Sicherheit durch Ziehen einer logischen Grenze zwischen Branches oder Tags.
Mit Workflowausführungen können Caches wiederhergestellt werden, die entweder im aktuellen Branch oder im Standardbranch (üblicherweise main
) erstellt wurden. Wenn eine Workflowausführung für einen Pull Request ausgelöst wird, kann sie auch Caches wiederherstellen, die im Basisbranch erstellt wurden, einschließlich der Basisbranches von geforkten Repositorys. Wenn der Branch feature-b
beispielsweise den Basisbranch feature-a
verwendet, hat ein Workflow, der durch einen Pull Request ausgelöst wird, Zugriff auf die Caches, die im Standardbranch main
, dem Basisbranch feature-a
und dem aktuellen Branch feature-b
erstellt wurden.
Mit Workflowausführungen können keine Caches wiederhergestellt werden, die für untergeordnete oder gleichgeordnete Branches erstellt wurden. Beispielsweise wäre ein für den untergeordneten Branch feature-b
erstellter Cache nicht für einen Workflow zugänglich, der für den übergeordneten Branch main
ausgelöst wurde. Ebenso wäre ein Cache, der für den Branch feature-a
mit der Basis main
erstellt wurde, nicht für den gleichgeordneten Branch feature-c
mit der Basis main
zugänglich. Mithilfe von Workflowausführungen können auch keine Caches wiederhergestellt werden, die für andere Tagnamen erstellt wurden. Zum Beispiel wäre ein Cache, der für das Tag release-a
mit der Basis main
erstellt wurde, nicht für eine Workflowausführung zugänglich, die für das Tag release-b
mit der Basis main
ausgelöst wurde.
Wenn ein Cache über eine Workflowausführung erstellt wird, die durch einen Pull Request ausgelöst wurde, wird der Cache für den Mergeverweis (refs/pull/.../merge
) erstellt. Aus diesem Grund hat der Cache einen begrenzten Bereich und kann nur durch erneutes Ausführen des Pull Request wiederhergestellt werden. Er kann nicht über den Basisbranch oder andere Pull Requests wiederhergestellt werden, die diesen Basisbranch als Ziel haben.
Mehrere Workflowausführungen in einem Repository können Caches gemeinsam nutzen. Ein Cache, der für einen Branch in einer Workflowausführung erstellt wurde, kann von einer anderen Workflowausführung für dasselbe Repository und denselben Branch aufgerufen und wiederhergestellt werden.
Verwenden der cache
-Aktion
Die cache
-Aktion versucht, einen Cache basierend auf dem bereitgestellten key
wiederherzustellen. Wenn die Aktion einen Cache findet, der exakt mit dem Schlüssel übereinstimmt, stellt die Aktion die zwischengespeicherten Dateien an dem von dir konfigurierten Pfad (path
) wieder her.
Du kannst optional eine Liste von restore-keys
angeben, die verwendet werden sollen, falls key
nicht mit einem vorhandenen Cache übereinstimmt. Eine Liste von restore-keys
ist nützlich, wenn du einen Cache aus einem anderen Branch wiederherstellst, da restore-keys
einen Teilabgleich für Cacheschlüssel durchführen kann. Weitere Informationen zum Abgleichen von restore-keys
findest du unter Abgleichen eines Cacheschlüssels.
Wenn es eine genaue Übereinstimmung mit dem angegebenen key
gibt, wird dies als Cachetreffer gewertet. Wenn kein Cache genau mit den angegebenen key
übereinstimmt, wird dies als Cachefehler gewertet. Bei einem Cachefehler erstellt die Aktion automatisch einen neuen Cache, wenn der Auftrag erfolgreich abgeschlossen wurde. Der neue Cache verwendet den bereitgestellten key
und enthält die von Ihnen in path
angegebenen Dateien. Weitere Informationen zur Handhabung dieser Situation findest du unter Cachetreffer und -fehler.
Du kannst den Inhalt eines vorhandenen Caches nicht ändern. Stattdessen kannst du einen neuen Cache mit einem neuen Schlüssel erstellen.
Eingabeparameter für die cache
-Aktion
-
key
: Erforderlich. Der Schlüssel, der beim Speichern eines Caches erstellt wurde, und der Schlüssel, der zum Suchen nach einem Cache verwendet wird. Dies kann eine beliebige Kombination von Variablen, Kontextwerten, statischen Zeichenfolgen und Funktionen sein. Schlüssel haben eine maximale Länge von 512 Zeichen und Schlüssel, die die maximale Länge überschreiten, lassen die Aktion fehlschlagen. -
path
: Erforderlich. Die Pfade auf dem Runner, die zwischengespeichert oder wiederhergestellt werden sollen.-
Du kannst einen einzelnen Pfad angeben oder mehrere Pfade in separaten Zeilen hinzufügen. Beispiel:
- name: Cache Gradle packages uses: actions/cache@v3 with: path: | ~/.gradle/caches ~/.gradle/wrapper
-
Du kannst entweder Verzeichnisse oder einzelne Dateien angeben, und Globmuster werden unterstützt.
-
Du kannst absolute Pfade oder zum Arbeitsbereichsverzeichnis relative Pfade angeben.
-
-
restore-keys
: Optional. Eine Zeichenfolge mit alternativen Wiederherstellungsschlüsseln, wobei jeder Wiederherstellungsschlüssel in einer neuen Zeile platziert wird. Wenn kein Cachetreffer fürkey
vorhanden ist, werden diese Wiederherstellungsschlüssel sequenziell in der bereitgestellten Reihenfolge verwendet, um einen Cache zu finden und wiederherzustellen. Beispiel:restore-keys: | npm-feature-${{ hashFiles('package-lock.json') }} npm-feature- npm-
-
enableCrossOsArchive
: Optional Ein boolescher Wert, bei dessen Aktivierung Windows-Runner Caches speichern oder wiederherstellen können, und zwar unabhängig vom Betriebssystem, auf dem der Cache erstellt wurde. Wird dieser Parameter nicht definiert, ist er standardmäßig auffalse
festgelegt. Weitere Informationen findest du unter Betriebssystemübergreifender Cache in der Dokumentation zum Actions-Cache.
Ausgabeparameter für die cache
-Aktion
cache-hit
: Ein boolescher Wert, der angibt, dass eine genaue Übereinstimmung für den Schlüssel gefunden wurde.
Cachetreffer und -fehler
Wenn key
exakt mit einem vorhandenen Cache übereinstimmt, wird dies als Cachetreffer bezeichnet, und die Aktion stellt die zwischengespeicherten Dateien im Verzeichnis path
wieder her.
Wenn key
nicht mit einem vorhandenen Cache übereinstimmt, wird das als Cachefehler bezeichnet. Wenn der Auftrag erfolgreich abgeschlossen wird, wird automatisch ein neuer Cache erstellt.
Wenn ein Cachefehler auftritt, sucht die Aktion auch in den angegebenen restore-keys
nach Übereinstimmungen:
- Wenn du
restore-keys
angibst, sucht diecache
-Aktion sequenziell nach Caches, die der Liste vonrestore-keys
entsprechen.- Wenn es eine genaue Übereinstimmung gibt, stellt die Aktion die Dateien aus dem Cache im Verzeichnis
path
wieder her. - Wenn es keine exakten Übereinstimmungen gibt, sucht die Aktion nach partiellen Übereinstimmungen der „restore keys“ (Wiederherstellungs-Scvhlüssel). Wenn die Aktion eine partielle Übereinstimmung findet, wird der aktuellste Cache im Verzeichnis
path
wiederhergestellt.
- Wenn es eine genaue Übereinstimmung gibt, stellt die Aktion die Dateien aus dem Cache im Verzeichnis
- Die
cache
-Aktion wird abgeschlossen, und der nächste Schritt im Auftrag wird ausgeführt. - Wenn der Auftrag erfolgreich abgeschlossen wurde, erstellt die Aktion automatisch einen neuen Cache mit dem Inhalt des Verzeichnisses
path
.
Eine ausführlichere Erläuterung des Cacheabgleichs findest du unter Abgleichen eines Cacheschlüssels.
Beispiel für die Verwendung der cache
-Aktion
Dieses Beispiel erstellt einen neuen Cache, wenn sich die Pakete in package-lock.json
ändern oder sich das Betriebssystem des Runners ändert. Das folgende Beispiel verwendet Kontexte und Ausdrücke, um einen Schlüssel zu generieren, der eine Kennung des Runnerbetriebssystems und einen SHA-256-Hash der Datei package-lock.json
enthält.
name: Caching with npm on: push jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Cache node modules id: cache-npm uses: actions/cache@v3 env: cache-name: cache-node-modules with: # npm cache files are stored in `~/.npm` on Linux/macOS path: ~/.npm key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }} restore-keys: | ${{ runner.os }}-build-${{ env.cache-name }}- ${{ runner.os }}-build- ${{ runner.os }}- - if: ${{ steps.cache-npm.outputs.cache-hit != 'true' }} name: List the state of node modules continue-on-error: true run: npm list - name: Install dependencies run: npm install - name: Build run: npm run build - name: Test run: npm test
name: Caching with npm
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Cache node modules
id: cache-npm
uses: actions/cache@v3
env:
cache-name: cache-node-modules
with:
# npm cache files are stored in `~/.npm` on Linux/macOS
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
${{ runner.os }}-build-
${{ runner.os }}-
- if: ${{ steps.cache-npm.outputs.cache-hit != 'true' }}
name: List the state of node modules
continue-on-error: true
run: npm list
- name: Install dependencies
run: npm install
- name: Build
run: npm run build
- name: Test
run: npm test
Cache-Keys aus Kontexten erstellen
Ein Cache-Key (Cache-Schlüssel) kann Kontexte, Funktionen, Literale und Operatoren enthalten, die von GitHub Actions unterstützt werden. Weitere Informationen findest du unter Zugreifen auf kontextbezogene Informationen zu Workflowausführungen und unter Auswerten von Ausdrücken in Workflows und Aktionen.
Wenn du zum Erstellen eines key
s Ausdrücke verwendest, kannst du automatisch einen neuen Cache erstellen, wenn sich Abhängigkeiten ändern.
Du kannst z. B. einen key
mit einem Ausdruck erstellen, der den Hash einer npm-Datei package-lock.json
berechnet. Wenn sich also die Abhängigkeiten ändern, aus denen die Datei package-lock.json
besteht, ändert sich der Cacheschlüssel, und ein neuer Cache wird automatisch erstellt.
npm-${{ hashFiles('package-lock.json') }}
GitHub wertet den Ausdruck hash "package-lock.json"
aus, um den endgültigen key
abzuleiten.
npm-d5ea0750
Verwenden der Ausgabe der cache
-Aktion
Du kannst die Ausgabe der cache
-Aktion verwenden, um eine Aktion abhängig davon auszuführen, ob ein Cachetreffer oder -fehler aufgetreten ist. Wenn eine genaue Übereinstimmung für einen Cache des angegebenen key
-Elements gefunden wird, wird die Ausgabe von cache-hit
auf true
festgelegt.
Im Beispielworkflow oben gibt es einen Schritt, in dem der Status der Node-Module aufgelistet wird, wenn ein Cachefehler aufgetreten ist:
- if: ${{ steps.cache-npm.outputs.cache-hit != 'true' }}
name: List the state of node modules
continue-on-error: true
run: npm list
Einen Cache-Key abgleichen
Die Aktion cache
sucht zunächst nach Cachetreffern für key
und den Cache Version in dem Branch, der die Workflowausführung enthält. Wenn es keinen Treffer gibt, wird nach restore-keys
und der Version gesucht. Wenn es im aktuellen Branch weiterhin keine Treffer gibt, wiederholt die Aktion cache
dieselben Schritte für den Standardbranch. Beachte, dass während der Suche die Bereichseinschränkungen gelten. Weitere Informationen findest du unter Einschränkungen für den Zugriff auf einen Cache.
Über die Cacheversion kann ein Cache mit Metadaten für den path
und das bei der Cacheerstellung verwendete Komprimierungstool versehen werden. So wird sichergestellt, dass die Workflowausführung eindeutig einem Cache entspricht, den sie tatsächlich dekomprimieren und nutzen kann. Weitere Informationen findest du unter Cacheversion in der Dokumentation zum Actions-Cache.
restore-keys
ermöglicht es Ihnen, eine Liste alternativer Wiederherstellungsschlüssel anzugeben, die verwendet werden sollen, wenn ein Cachefehler für key
auftritt. Du kannst mehrere restore-keys
erstellen, die von den spezifischsten zum am wenigsten spezifischen sortiert sind. Die cache
-Aktion durchsucht die restore-keys
sequenzielle Reihenfolge. Wenn ein Schlüssel nicht direkt übereinstimmt, sucht die Aktion nach Schlüsseln denen der Restore-Key vorangestellt ist. Wenn mehrere Teiltreffer für einen Restore-Key vorhanden sind, gibt die Aktion den zuletzt erstellten Cache zurück.
Beispiel für die Verwendung mehrerer Restore-Keys
restore-keys: |
npm-feature-${{ hashFiles('package-lock.json') }}
npm-feature-
npm-
Der Runner wertet die Ausdrücke aus, die in die folgenden restore-keys
aufgelöst werden:
restore-keys: |
npm-feature-d5ea0750
npm-feature-
npm-
Der Wiederherstellungsschlüssel npm-feature-
stimmt mit jedem Schlüssel überein, der mit der Zeichenfolge npm-feature-
beginnt. Beispielsweise entsprechen beide Schlüssel npm-feature-fd3052de
und npm-feature-a9b253ff
dem Wiederherstellungsschlüssel. Der Cache mit dem neuesten Erstellungsdatum wird verwendet. Die Schlüssel in diesem Beispiel werden in der folgenden Reihenfolge durchsucht:
npm-feature-d5ea0750
stimmt mit einem bestimmten Hash überein.npm-feature-
gleicht Cacheschlüssel mit dem Präfixnpm-feature-
ab.npm-
gleicht alle Schlüssel mit dem Präfixnpm-
ab.
Beispiel für die Suchpriorität
key:
npm-feature-d5ea0750
restore-keys: |
npm-feature-
npm-
Wenn beispielsweise ein Pull Request einen feature
-Branch enthält und auf den Standardbranch (main
) abzielt, sucht die Aktion nach key
und restore-keys
in der folgenden Reihenfolge:
- Schlüssel
npm-feature-d5ea0750
imfeature
-Branch - Schlüssel
npm-feature-
imfeature
-Branch - Schlüssel
npm-
imfeature
-Branch - Schlüssel
npm-feature-d5ea0750
immain
-Branch - Schlüssel
npm-feature-
immain
-Branch - Schlüssel
npm-
immain
-Branch
Nutzungsbeschränkungen und Räumungsrichtlinien
GitHub wird alle Cache-Einträge entfernen, auf die seit mehr als 7 Tagen nicht zugegriffen wurde. Es gibt keine Grenze für die Anzahl der Caches, die du speichern kannst. Die Gesamtgröße aller Caches in einem Repository ist jedoch begrenzt. Standardmäßig liegt der Grenzwert bei 10 GB pro Repository. Dieser Grenzwert kann jedoch je nach den von deinen Unternehmensinhaberinnen oder Repositoryadministratorinnen festgelegten Richtlinien abweichen. Sobald ein Repository seinen maximalen Cachespeicher erreicht hat, wird durch die Cacheentfernungsrichtlinie Speicherplatz geschaffen, indem die ältesten Caches im Repository gelöscht werden.
Wenn du diesen Grenzwert überschreitest, wird GitHub den neuen Cache speichern, jedoch auch damit beginnen, Caches zu löschen, bis die Gesamtgröße kleiner als das Limit des Repositorys ist. Der Prozess zur Cacheleerung kann zu einem sogenannten Cache-Thrashing führen, bei dem Caches in hoher Frequenz erstellt und gelöscht werden. Um dies zu reduzieren, kannst du die Caches für ein Repository überprüfen und Korrekturmaßnahmen ergreifen, wie z. B. das Entfernen der Zwischenspeicherung aus bestimmten Workflows. Weitere Informationen findest du unter Verwalten von Caches. Du kannst auch das Cachegrößenlimit für ein Repository erhöhen. Weitere Informationen findest du unter Verwalten von GitHub Actions-Einstellungen für ein Repository.
Verwalten von Caches
Zum Verwalten der über deine Workflows erstellten Caches kannst du folgende Aufgaben ausführen:
- Anzeigen einer Liste aller Cacheeinträge für ein Repository
- Filtern und Sortieren der Liste der Caches anhand bestimmter Metadaten, z. B. Cachegröße, Erstellungszeitpunkt oder Zeitpunkt des letzten Zugriffs
- Löschen von Cacheeinträgen aus einem Repository
- Überwachen der aggregierten Cachenutzung für Repositorys und Organisationen
Es gibt mehrere Möglichkeiten, die Caches für deine Repositorys zu verwalten:
-
Verwenden der GitHub-Weboberfläche, wie unten gezeigt.
-
Verwendung der REST-API. Weitere Informationen findest du unter REST-API-Endpunkte für GitHub-Actions-Cache.
-
Installieren des
gh cache
-Unterbefehls zum Verwalten Ihrer Caches über die Befehlszeile. Weitere Informationen finden Sie in der Dokumentation zur GitHub-CLI.Hinweis: Stellen Sie bei manueller Ausführung sicher, dass Version 2.32.0 oder höher der CLI installiert ist.
Anzeigen von Cacheeinträgen
Du kannst die Weboberfläche verwenden, um eine Liste der Cacheeinträge für ein Repository anzuzeigen. In der Cacheliste kannst du sehen, wie viel Speicherplatz jeder Cache verbraucht, wann der Cache erstellt und wann er zuletzt verwendet wurde.
-
Navigieren Sie auf GitHub zur Hauptseite des Repositorys.
-
Klicke unter dem Namen deines Repositorys auf Aktionen.
-
Klicke auf der linken Seitenleiste unter dem Abschnitt „Verwaltung“ auf Caches.
-
Überprüfe die Liste der Cacheeinträge für das Repository.
- Um nach Cacheeinträgen zu suchen, die für einen bestimmten Branch verwendet werden, klicke auf das Dropdownmenü Branch, und wähle einen Branch aus. In der Cacheliste werden alle Caches angezeigt, die für den ausgewählten Branch verwendet werden.
- Um nach Cacheeinträgen mit einem bestimmten Cacheschlüssel zu suchen, verwende die Syntax
key: key-name
im Feld Caches filtern. In der Cacheliste werden Caches aus allen Branches angezeigt, in denen der Schlüssel verwendet wurde.
Löschen von Cacheeinträgen
Benutzer mit write
-Zugriff auf ein Repository können die GitHub-Weboberfläche verwenden, um Cacheeinträge zu löschen.
-
Navigieren Sie auf GitHub zur Hauptseite des Repositorys.
-
Klicke unter dem Namen deines Repositorys auf Aktionen.
-
Klicke auf der linken Seitenleiste unter dem Abschnitt „Verwaltung“ auf Caches.
-
Klicke rechts neben dem Cacheeintrag, den du löschen möchtest, auf .
Erzwingen des Löschens von Cacheeinträgen
Caches verfügen über Branchumfangseinschränkungen. Das bedeutet, dass einige Caches eingeschränkte Nutzungsoptionen besitzen. Weitere Informationen zu Einschränkungen für den Cacheumfang findest du unter Abhängigkeiten zwischenspeichern um Workflows zu beschleunigen. Wenn auf einen bestimmten Branch begrenzte Caches ein hohes Speicherkontingent verbrauchen, kann dies dazu führen, dass Caches aus dem Branch default
häufig erstellt und gelöscht werden.
In einem Repository könnten beispielsweise viele neue Pull Requests geöffnet werden, die jeweils über eigene Caches verfügen, die auf diesen Branch beschränkt sind. Diese Caches könnten den Großteil des Cachespeichers dieses Repository belegen. Sobald ein Repository seinen maximalen Cachespeicher erreicht hat, wird durch die Cacheentfernungsrichtlinie Speicherplatz geschaffen, indem die ältesten Caches im Repository gelöscht werden. Um in diesem Fall ein Cache-Thrashing zu verhindern, kannst du Workflows einrichten, mit denen Caches schneller gelöscht werden als über die Richtlinie zur Cacheentleerung. Du kannst die CLI-Erweiterung gh-actions-cache
verwenden, um Caches für bestimmte Branches zu löschen.
Im folgenden Beispielworkflow wird gh-actions-cache
zum Löschen von bis zu 100 von einem Branch erstellten Caches verwendet, sobald ein Pull Request geschlossen wird.
Sie können den Workflow mit dem Ereignis pull_request_target
auslösen, um das folgende Beispiel für repositoryübergreifende Pull Requests oder für Pull Requests von Forks auszuführen. Wenn Sie den Workflow mit pull_request_target
auslösen, sollten Sie die entsprechenden Sicherheitsaspekte berücksichtigen. Weitere Informationen findest du unter Ereignisse zum Auslösen von Workflows.
name: cleanup caches by a branch
on:
pull_request:
types:
- closed
jobs:
cleanup:
runs-on: ubuntu-latest
steps:
- name: Cleanup
run: |
gh extension install actions/gh-actions-cache
echo "Fetching list of cache key"
cacheKeysForPR=$(gh actions-cache list -R $REPO -B $BRANCH -L 100 | cut -f 1 )
## Setting this to not fail the workflow while deleting cache keys.
set +e
echo "Deleting caches..."
for cacheKey in $cacheKeysForPR
do
gh actions-cache delete $cacheKey -R $REPO -B $BRANCH --confirm
done
echo "Done"
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
REPO: ${{ github.repository }}
BRANCH: refs/pull/${{ github.event.pull_request.number }}/merge
Alternativ kannst du die API verwenden, um alle Caches automatisch in einem eigenen Intervall aufzulisten oder zu löschen. Weitere Informationen findest du unter REST-API-Endpunkte für GitHub-Actions-Cache.