# Referenz zum Zwischenspeichern von Abhängigkeiten Hier findest du Informationen zur Funktionalität des Zwischenspeicherns von Abhängigkeiten in Workflows. ## Nutzung der `cache`-Aktion Durch die [`cache`-Aktion](https://github.com/actions/cache) wird versucht beim Wiederherstellen eines Caches versucht, die folgende Sequenz auszuführen: 1. Zunächst wird nach einer genauen Übereinstimmung mit dem bereitgestellten `key`-Element gesucht. 2. Wenn keine genaue Übereinstimmung gefunden wird, wird nach teilweisen Übereinstimmungen für das `key`-Element gesucht. 3. Wenn trotzdem keine Übereinstimmung gefunden wurde und du `restore-keys` angegeben hast, werden diese Schlüssel sequenziell auf teilweise Übereinstimmung überprüft. Weitere Informationen findest du unter [Abgleichen eines Cacheschlüssels](#cache-key-matching). 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](#cache-hits-and-misses). 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: ```yaml - name: Cache Gradle packages uses: actions/cache@v4 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ür `key` vorhanden ist, werden diese Wiederherstellungsschlüssel sequenziell in der bereitgestellten Reihenfolge verwendet, um einen Cache zu finden und wiederherzustellen. Beispiel: ```yaml 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 auf `false` festgelegt. Weitere Informationen findest du unter [Betriebssystemübergreifender Cache](https://github.com/actions/cache/blob/main/tips-and-workarounds.md#cross-os-cache) in der Dokumentation zum Actions-Cache. > \[!NOTE] > Es wird empfohlen, keine vertraulichen Informationen wie Zugriffstoken oder Anmeldeinformationen in Dateien im Cachepfad zu speichern. Jeder Benutzer mit Lesezugriff kann einen Pull-Request für ein Repository erstellen und auf den Inhalt des Caches zugreifen. Darüber hinaus können Forks eines Repositorys Pull Requests für den Basisbranch erstellen und auf Caches im Basisbranch zugreifen. ### 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: 1. Wenn du `restore-keys` angibst, sucht die `cache`-Aktion sequenziell nach Caches, die der Liste von `restore-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. 2. Die `cache`-Aktion wird abgeschlossen, und der nächste Schritt im Auftrag wird ausgeführt. 3. 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](#cache-key-matching). ### 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. ```yaml copy name: Caching with npm on: push jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - name: Cache node modules id: cache-npm uses: actions/cache@v4 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 Cacheschlüssel kann jede der von GitHub Actions unterstützten Kontexte, Funktionen, Literale und Operatoren enthalten. Weitere Informationen findest du unter [Kontextreferenz](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts) und [Auswerten von Ausdrücken in Workflows und Aktionen](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions). 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. ```yaml npm-${{ hashFiles('package-lock.json') }} ``` GitHub wertet den Ausdruck `hash "package-lock.json"` aus, um das Endgültige `key`abzuleiten. ```yaml 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: ```yaml - if: ${{ steps.cache-npm.outputs.cache-hit != 'true' }} name: List the state of node modules continue-on-error: true run: npm list ``` ## Abgleichen eines Cacheschlüssels 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 kein Treffer vorhanden ist, wird nach Präfixübereinstimmungen für `key` gesucht. Sollten dabei trotzdem kein Treffer gefunden werden, wird nach `restore-keys` und der *Version* gesucht. Wenn im aktuellen Branch immer noch keine Treffer vorhanden sind, führt die `cache`-Aktion dieselben Schritte im Standardbranch erneut aus. Beachte, dass während der Suche die Bereichseinschränkungen gelten. Weitere Informationen findest du unter [Einschränkungen für den Zugriff auf einen Cache](#restrictions-for-accessing-a-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](https://github.com/actions/cache#cache-version) 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 Wiederherstellungsschlüssel 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 ```yaml 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: ```yaml 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: 1. \*\* `npm-feature-d5ea0750` \*\* stimmt mit einem bestimmten Hash überein. 2. \*\* `npm-feature-` \*\* gleicht Cacheschlüssel mit dem Präfix `npm-feature-` ab. 3. \*\* `npm-` \*\* gleicht alle Schlüssel mit dem Präfix `npm-` ab. #### Beispiel für die Suchpriorität ```yaml 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: 1. Schlüssel `npm-feature-d5ea0750` im `feature`-Branch 2. Schlüssel `npm-feature-` im `feature`-Branch 3. Schlüssel `npm-` im `feature`-Branch 4. Schlüssel `npm-feature-d5ea0750` im `main`-Branch 5. Schlüssel `npm-feature-` im `main`-Branch 6. Schlüssel `npm-` im `main`-Branch ## `setup-*`-Aktionen für bestimmte Paket-Manager 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](https://github.com/actions/setup-node#caching-global-packages-data) | | | pip, pipenv, Poesie | | | [setup-python](https://github.com/actions/setup-python#caching-packages-dependencies) | | | Gradle, Maven | | | [setup-java](https://github.com/actions/setup-java#caching-packages-dependencies) | | | RubyGems | | | [setup-ruby](https://github.com/ruby/setup-ruby#caching-bundle-install-automatically) | | | Los `go.sum` | | | [setup-go](https://github.com/actions/setup-go#caching-dependency-files-and-build-outputs) | | | .NET NuGet | | | [setup-dotnet](https://github.com/actions/setup-dotnet?tab=readme-ov-file#caching-nuget-packages) | | ## 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. > \[!NOTE] > Da Objekte von Runnern direkt aus dem Cache abgerufen oder direkt in den Cache eingefügt werden, müssen Actions-Runner direkten Zugriff auf den in GitHub Enterprise Server konfigurierten Actions-Objektspeicher haben, beispielsweise AWS S3 oder Azure Blob Storage. Selbstgehostete Runner authentifizieren sich beim Blobspeicheranbieter mithilfe einer Zugriffs-URL, die von der Instanz GitHub Enterprise Server bereitgestellt wird. Diese URL stellt dem Blob Storage-Anbieter gültige temporäre Authentifizierungsanmeldeinformationen bereit. Dieser Prozess wird von der Instanz selbst initiiert, die alle Anforderungen an den Objektspeicher vermittelt. > > Dies bedeutet, dass `actions/cache` eine HTTPS-Verbindung mit der Blob Storage-Instanz benötigt, um ordnungsgemäß zu funktionieren. > > Alle Metadaten werden vom Artefakt-Cache-Dienst verwaltet, der ein Mikroservice innerhalb von GitHub Actions ist. > > Weitere Informationen zum Cachespeicher findest du unter [Anforderungen für den externen Speicher](/de/enterprise-server@3.22/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-server#external-storage-requirements). ## Cachezugriff für Workflowtrigger mit niedriger Vertrauensebene Einige Workflows werden als Reaktion auf Ereignisse ausgeführt, die von Personen initiiert werden können, die keinen Schreibzugriff auf das Repository haben, z. B. eine Fork-Pullanforderung oder ein Problemkommentar. Wenn diese Ereignisse im Kontext des Standard-Branchs ausgeführt werden, könnten sie dazu verwendet werden, einen bösartigen Cache anzulegen, den ein späterer, stärker privilegierter Workflow wiederherstellt und dem er vertraut. Diese Angriffsklasse wird als *Cachevergiftung* bezeichnet. Um dieses Risiko zu verringern, können nur diese Workflowtrigger Caches im Bereich der Standardverzweigung erstellen oder überschreiben: * `push` * `workflow_dispatch` * `repository_dispatch` * `delete` * `registry_package` * `page_build` * `schedule` Durch ein anderes Ereignis ausgelöste Ausführungen, das zur Standardverzweigung führt, erhalten schreibgeschützten Zugriff auf Caches innerhalb des Geltungsbereichs der Standardverzweigung. Diese Ausführungen können vorhandene Caches wiederherstellen, aber keine Caches erstellen oder überschreiben. Dazu gehören Trigger, deren Nutzlast oder auslösender Akteur von jemandem außerhalb des Repositorys beeinflusst werden können, z. B. `pull_request_target`, `issue_comment` und `workflow_run`. Das `pull_request` Ereignis wird nicht beeinflusst. Caches, die durch einen `pull_request`-Lauf erstellt wurden, sind bereits dem Merge-Ref (`refs/pull/.../merge`) zugeordnet und können nicht in den Geltungsbereich des Standard-Branches geschrieben werden. Weitere Informationen findest du unter [Einschränkungen für den Zugriff auf einen Cache](#restrictions-for-accessing-a-cache). Wenn eine Ausführung mit schreibgeschütztem Zugriff auf den Cache versucht, den Cache zu speichern, schlägt der Speichervorgang fehl, aber der Schritt und der Job schlagen nicht fehl. Der Workflow wird fortgesetzt, und der Fehler wird als Warnung im Workflowprotokoll gemeldet. Beachten Sie in diesem Fall Folgendes: * Um die Leistungsvorteile des Caching im Gültigkeitsbereich des Standard-Branches beizubehalten, stellen Sie sicher, dass ein vertrauenswürdiger Workflow eingerichtet ist, der den Cache aktualisiert, beispielsweise ein CI-Build, der durch ein `push` an den Standard-Branch ausgelöst wird. Diese Cache-Einträge können dann durch Workflows wiederhergestellt werden, die durch Ereignisse mit geringem Vertrauensniveau ausgelöst werden, wie `pull_request_target`. * Wechseln Sie in Workflows mit geringem Vertrauensniveau zu einem reinen Cache-Wiederherstellungsvorgang wie `actions/cache/restore`, um die beabsichtigte Cache-Nutzung deutlich zu machen und die Warnung in den Protokollen der Workflowausführung zu vermeiden. ## Bewährte Methoden für die sichere Verwendung von Caches Cacheinhalte sind nicht signiert oder überprüft, und alle Workflowausführungen, die einen Cache lesen können, können deren Inhalt extrahieren. Extrahierte Caches können Dateien ändern, die anschließend in einer Workflowausführung ausgeführt werden, was zur Ausführung bösartigen Codes führt. Befolgen Sie diese Methoden, um das Sicherheitsrisiko bei der Verwendung von Caches zu verringern. * **Speichern Sie vertrauliche Informationen nicht in einem Cache.** Jeder, der eine Pullanforderung für Ihr Repository öffnen kann, kann den Inhalt von Caches in der Base Branch lesen. Schreiben Sie keine geheimen Schlüssel, Token oder Anmeldeinformationen in einen zwischengespeicherten Pfad. Speichern Sie vertrauliche Werte stattdessen als geheime Schlüssel. Siehe [Geheimnisse](/de/enterprise-server@3.22/actions/concepts/security/secrets). * **Speichern Sie Caches bei vertrauenswürdigen Triggern.** Einschränken von Cache-Schreibvorgängen auf Workflows, die von vertrauenswürdigen Akteuren ausgelöst werden (in der Regel solche mit Schreibzugriff auf das Repository). Siehe [Cachezugriff für Workflowtrigger mit niedriger Vertrauensebene](#cache-access-for-low-trust-workflow-triggers) für die Standardeinschränkungen, die erzwungen werden, um zu begrenzen, welche Workflowtrigger in den Cache schreiben können. Darüber hinaus sollten Sie Umgebungen mit Bereitstellungsschutzregeln verwenden, um die Workflows, die den Cache ändern können, weiter einzuschränken. Siehe [Verwalten von Umgebungen für die Bereitstellung](/de/enterprise-server@3.22/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments). * **Befolgen Sie bewährte Methoden für die Workflowsicherheit, um Ihre Workflows zu härten:** Beschränken Sie Workflows mit Cache-Schreibzugriff auf diejenigen, die gegen Workflowrisiken gehärtet wurden. Befolgen Sie die Anleitungen bei [Referenz zur sicheren Verwendung](/de/enterprise-server@3.22/actions/reference/security/secure-use#writing-workflows) , um Sicherheitsrisiken in Ihren Workflows zu verhindern, die zur Codeausführung und zur Einführung bösartiger Cacheeinträge führen könnten. Eine umfassendere Anleitung zum Sichern Ihrer Workflows finden Sie unter [Referenz zur sicheren Verwendung](/de/enterprise-server@3.22/actions/reference/security/secure-use). ## Nutzungsbeschränkungen und Räumungsrichtlinien GitHub legt Beschränkungen für den Cache-Speicher und die Aufbewahrungsdauer fest, um Speicherkosten zu verwalten und Missbrauch zu verhindern. Wenn Sie diese Grenzwerte verstehen, können Sie die Cachenutzung optimieren. ### Standardgrenzwerte GitHub entfernt alle Cacheeinträge, auf die in mehr als 7 Tagen nicht zugegriffen wurde. Es gibt keine Beschränkung für die Anzahl der Caches, die Sie speichern können, aber die Gesamtgröße aller Caches in einem Repository ist begrenzt. Standardmäßig beträgt der Grenzwert 10 GB pro Repository, aber dieser Grenzwert kann von Unternehmensbesitzern, Organisationsbesitzern oder Repositoryadministratoren erhöht werden. Sobald ein Repository seinen maximalen Cachespeicher erreicht hat, erstellt die Cache-Löschrichtlinie Speicherplatz, indem die Caches in der Reihenfolge des letzten Zugriffsdatums gelöscht werden, von der ältesten bis zur neuesten. 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 Cache-Löschvorgang kann zu Cache-Thrashing führen, bei dem Caches mit hoher Häufigkeit erstellt und gelöscht werden. Um dies zu verringern, können Sie die Caches für ein Repository überprüfen und Korrekturmaßnahmen ergreifen, z. B. das Entfernen der Zwischenspeicherung aus bestimmten Workflows. Siehe [Verwalten von Caches](/de/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/manage-caches). Sie können auch den Grenzwert für die Cachegröße für ein Repository erhöhen. Weitere Informationen findest du unter [Einstellung der GitHub Actions für ein Repository verwalten](/de/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-cache-storage-for-a-repository). ## Nächste Schritte Informationen zum Verwalten von Abhängigkeitscaches findest du unter [Verwalten von Caches](/de/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/manage-caches).