{"meta":{"title":"Referenz zum Zwischenspeichern von Abhängigkeiten","intro":"Hier findest du Informationen zur Funktionalität des Zwischenspeicherns von Abhängigkeiten in Workflows.","product":"GitHub Actions","breadcrumbs":[{"href":"/de/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/de/enterprise-cloud@latest/actions/reference","title":"Verweis"},{"href":"/de/enterprise-cloud@latest/actions/reference/workflows-and-actions","title":"Workflows und Aktionen"},{"href":"/de/enterprise-cloud@latest/actions/reference/workflows-and-actions/dependency-caching","title":"Zwischenspeichern von Abhängigkeiten"}],"documentType":"article"},"body":"# Referenz zum Zwischenspeichern von Abhängigkeiten\n\nHier findest du Informationen zur Funktionalität des Zwischenspeicherns von Abhängigkeiten in Workflows.\n\n## Nutzung der `cache`-Aktion\n\nDurch die [`cache`-Aktion](https://github.com/actions/cache) wird versucht beim Wiederherstellen eines Caches versucht, die folgende Sequenz auszuführen:\n\n1. Zunächst wird nach einer genauen Übereinstimmung mit dem bereitgestellten `key`-Element gesucht.\n2. Wenn keine genaue Übereinstimmung gefunden wird, wird nach teilweisen Übereinstimmungen für das `key`-Element gesucht.\n3. 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).\n\nWenn 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).\n\nDu kannst den Inhalt eines vorhandenen Caches nicht ändern. Stattdessen kannst du einen neuen Cache mit einem neuen Schlüssel erstellen.\n\n### Eingabeparameter für die `cache`-Aktion\n\n* `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.\n\n* `path`: **Erforderlich**. Die Pfade auf dem Runner, die zwischengespeichert oder wiederhergestellt werden sollen.\n  * Du kannst einen einzelnen Pfad angeben oder mehrere Pfade in separaten Zeilen hinzufügen. Beispiel:\n\n    ```yaml\n    - name: Cache Gradle packages\n      uses: actions/cache@v4\n      with:\n        path: |\n          ~/.gradle/caches\n          ~/.gradle/wrapper\n    ```\n\n  * Du kannst entweder Verzeichnisse oder einzelne Dateien angeben, und Globmuster werden unterstützt.\n\n  * Du kannst absolute Pfade oder zum Arbeitsbereichsverzeichnis relative Pfade angeben.\n\n* `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:\n\n  ```yaml\n  restore-keys: |\n    npm-feature-${{ hashFiles('package-lock.json') }}\n    npm-feature-\n    npm-\n  ```\n\n* `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.\n\n> \\[!NOTE]\n> 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.\n\n### Ausgabeparameter für die `cache`-Aktion\n\n* `cache-hit`: Ein boolescher Wert, der angibt, dass eine genaue Übereinstimmung für den Schlüssel gefunden wurde.\n\n### Cachetreffer und -fehler\n\nWenn `key` exakt mit einem vorhandenen Cache übereinstimmt, wird dies als *Cachetreffer* bezeichnet, und die Aktion stellt die zwischengespeicherten Dateien im Verzeichnis `path` wieder her.\n\nWenn `key` nicht mit einem vorhandenen Cache übereinstimmt, wird das als *Cachefehler* bezeichnet. Wenn der Auftrag erfolgreich abgeschlossen wird, wird automatisch ein neuer Cache erstellt.\n\nWenn ein Cachefehler auftritt, sucht die Aktion auch in den angegebenen `restore-keys` nach Übereinstimmungen:\n\n1. Wenn du `restore-keys` angibst, sucht die `cache`-Aktion sequenziell nach Caches, die der Liste von `restore-keys` entsprechen.\n   * Wenn es eine genaue Übereinstimmung gibt, stellt die Aktion die Dateien aus dem Cache im Verzeichnis `path` wieder her.\n   * 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.\n2. Die `cache`-Aktion wird abgeschlossen, und der nächste Schritt im Auftrag wird ausgeführt.\n3. Wenn der Auftrag erfolgreich abgeschlossen wurde, erstellt die Aktion automatisch einen neuen Cache mit dem Inhalt des Verzeichnisses `path`.\n\nEine ausführlichere Erläuterung des Cacheabgleichs findest du unter [Abgleichen eines Cacheschlüssels](#cache-key-matching).\n\n### Beispiel für die Verwendung der `cache`-Aktion\n\nDieses 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.\n\n```yaml copy\nname: Caching with npm\non: push\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v6\n\n      - name: Cache node modules\n        id: cache-npm\n        uses: actions/cache@v4\n        env:\n          cache-name: cache-node-modules\n        with:\n          # npm cache files are stored in `~/.npm` on Linux/macOS\n          path: ~/.npm\n          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}\n          restore-keys: |\n            ${{ runner.os }}-build-${{ env.cache-name }}-\n            ${{ runner.os }}-build-\n            ${{ runner.os }}-\n\n      - if: ${{ steps.cache-npm.outputs.cache-hit != 'true' }}\n        name: List the state of node modules\n        continue-on-error: true\n        run: npm list\n\n      - name: Install dependencies\n        run: npm install\n\n      - name: Build\n        run: npm run build\n\n      - name: Test\n        run: npm test\n```\n\n### Cache-Keys aus Kontexten erstellen\n\nEin Cacheschlüssel kann jede der von GitHub Actions unterstützten Kontexte, Funktionen, Literale und Operatoren enthalten. Weitere Informationen findest du unter [Kontextreferenz](/de/enterprise-cloud@latest/actions/reference/workflows-and-actions/contexts) und [Auswerten von Ausdrücken in Workflows und Aktionen](/de/enterprise-cloud@latest/actions/reference/workflows-and-actions/expressions).\n\nWenn du zum Erstellen eines `key`s Ausdrücke verwendest, kannst du automatisch einen neuen Cache erstellen, wenn sich Abhängigkeiten ändern.\n\nDu 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.\n\n```yaml\nnpm-${{ hashFiles('package-lock.json') }}\n```\n\nGitHub wertet den Ausdruck `hash \"package-lock.json\"` aus, um das Endgültige `key`abzuleiten.\n\n```yaml\nnpm-d5ea0750\n```\n\n### Verwenden der Ausgabe der `cache`-Aktion\n\nDu 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.\n\nIm Beispielworkflow oben gibt es einen Schritt, in dem der Status der Node-Module aufgelistet wird, wenn ein Cachefehler aufgetreten ist:\n\n```yaml\n- if: ${{ steps.cache-npm.outputs.cache-hit != 'true' }}\n  name: List the state of node modules\n  continue-on-error: true\n  run: npm list\n```\n\n## Abgleichen eines Cacheschlüssels\n\nDie 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).\n\nÜ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.\n\n`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.\n\n### Beispiel für die Verwendung mehrerer Restore-Keys\n\n```yaml\nrestore-keys: |\n  npm-feature-${{ hashFiles('package-lock.json') }}\n  npm-feature-\n  npm-\n```\n\nDer Runner wertet die Ausdrücke aus, die in die folgenden `restore-keys` aufgelöst werden:\n\n```yaml\nrestore-keys: |\n  npm-feature-d5ea0750\n  npm-feature-\n  npm-\n```\n\nDer 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:\n\n1. \\*\\*\n   `npm-feature-d5ea0750`\n   \\*\\* stimmt mit einem bestimmten Hash überein.\n2. \\*\\*\n   `npm-feature-`\n   \\*\\* gleicht Cacheschlüssel mit dem Präfix `npm-feature-` ab.\n3. \\*\\*\n   `npm-`\n   \\*\\* gleicht alle Schlüssel mit dem Präfix `npm-` ab.\n\n#### Beispiel für die Suchpriorität\n\n```yaml\nkey:\n  npm-feature-d5ea0750\nrestore-keys: |\n  npm-feature-\n  npm-\n```\n\nWenn 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:\n\n1. Schlüssel `npm-feature-d5ea0750` im `feature`-Branch\n2. Schlüssel `npm-feature-` im `feature`-Branch\n3. Schlüssel `npm-` im `feature`-Branch\n4. Schlüssel `npm-feature-d5ea0750` im `main`-Branch\n5. Schlüssel `npm-feature-` im `main`-Branch\n6. Schlüssel `npm-` im `main`-Branch\n\n## `setup-*`-Aktionen für bestimmte Paket-Manager\n\nWenn 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.\n\n| Paket-Manager                                                                                     | Setup-\\*-Aktion zum Zwischenspeichern |\n| ------------------------------------------------------------------------------------------------- | ------------------------------------- |\n| npm, Yarn, pnpm                                                                                   |                                       |\n| [setup-node](https://github.com/actions/setup-node#caching-global-packages-data)                  |                                       |\n| pip, pipenv, Poesie                                                                               |                                       |\n| [setup-python](https://github.com/actions/setup-python#caching-packages-dependencies)             |                                       |\n| Gradle, Maven                                                                                     |                                       |\n| [setup-java](https://github.com/actions/setup-java#caching-packages-dependencies)                 |                                       |\n| RubyGems                                                                                          |                                       |\n| [setup-ruby](https://github.com/ruby/setup-ruby#caching-bundle-install-automatically)             |                                       |\n| Los `go.sum`                                                                                      |                                       |\n| [setup-go](https://github.com/actions/setup-go#caching-dependency-files-and-build-outputs)        |                                       |\n| .NET NuGet                                                                                        |                                       |\n| [setup-dotnet](https://github.com/actions/setup-dotnet?tab=readme-ov-file#caching-nuget-packages) |                                       |\n\n## Einschränkungen für den Zugriff auf einen Cache\n\nZugriffsbeschränkungen bieten Cache-Isolation und Sicherheit durch Ziehen einer logischen Grenze zwischen Branches oder Tags.\nMit 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.\n\nMit 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.\n\nWenn 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.\n\nMehrere 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.\n\n## Cachezugriff für Workflowtrigger mit niedriger Vertrauensebene\n\nEinige 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.\n\nUm dieses Risiko zu verringern, können nur diese Workflowtrigger Caches im Bereich der Standardverzweigung erstellen oder überschreiben:\n\n* `push`\n* `workflow_dispatch`\n* `repository_dispatch`\n* `delete`\n* `registry_package`\n* `page_build`\n* `schedule`\n\nDurch 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`.\n\nDas `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).\n\nWenn 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:\n\n* 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`.\n* 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.\n\n## Bewährte Methoden für die sichere Verwendung von Caches\n\nCacheinhalte 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.\n\n* **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-cloud@latest/actions/concepts/security/secrets).\n* **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-cloud@latest/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments).\n* **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-cloud@latest/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.\n\nEine umfassendere Anleitung zum Sichern Ihrer Workflows finden Sie unter [Referenz zur sicheren Verwendung](/de/enterprise-cloud@latest/actions/reference/security/secure-use).\n\n## Nutzungsbeschränkungen und Räumungsrichtlinien\n\nGitHub 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.\n\n### Standardgrenzwerte\n\nGitHub 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.\nJede Nutzung über 10 GB hinaus wird Ihrem Konto in Rechnung gestellt. 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.\n\nWenn 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 oder das Erhöhen der Cachegröße. Diese Funktion ist nur für Benutzer verfügbar, für die eine Zahlungsmethode hinterlegt ist und die sie durch Konfigurieren der Cache-Einstellungen aktivieren. Siehe [Verwalten von Caches](/de/enterprise-cloud@latest/actions/how-tos/manage-workflow-runs/manage-caches).\n\nSie können Cacheeinträge mit einer Rate von bis zu 200 Uploads pro Minute pro Repository erstellen und mit einer Rate von 1500 Downloads pro Minute pro Repository herunterladen. Wenn Sie diese Rate überschreiten, schlagen nachfolgende Cacheupload- oder Downloadversuche fehl, bis die entsprechenden Ratenbeschränkungen zurückgesetzt werden. Die Zeit bis zum Zurücksetzen des Ratenlimits wird im `Retry-After` Header der Antwort zurückgegeben. Weitere Informationen zu [](/de/enterprise-cloud@latest/actions/reference/limits) Ratenlimits finden Sie unter GitHub Actions.\n\n### Erhöhen der Cachegröße\n\nWenn Sie die Häufigkeit verringern möchten, mit der Cacheeinträge gelöscht werden, können Sie die Speichergrenzwerte für Den Cache in den Aktionseinstellungen erhöhen. Repositorys im Besitz von Benutzern können bis zu 10 TB pro Repository konfigurieren. Für Repositorys, die sich im Besitz von Organisationen befinden, wird der maximale konfigurierbare Grenzwert durch die Einstellungen der Organisation bestimmt. Für Organisationen, die sich im Besitz eines Unternehmens befinden, wird das maximale konfigurierbare Limit durch die Einstellungen des Unternehmens bestimmt. Eine Erhöhung des Grenzwerts über die Standardmäßigen 10 GB hinaus führt zu zusätzlichen Kosten, wenn dieser Speicher verwendet wird.\n\nWeitere Informationen finden Sie unter:\n\n* [Einstellung der GitHub Actions für ein Repository verwalten](/de/enterprise-cloud@latest/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-cache-settings-for-your-repository)\n* [Deaktivieren oder Einschränken von GitHub Actions für Ihre Organisation](/de/enterprise-cloud@latest/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#managing-github-actions-cache-storage-for-your-organization)\n* [Erzwingen von Richtlinien für GitHub Actions in Ihrem Unternehmen](/de/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#artifact-and-log-retention)\n\nDie Nutzung von zusätzlichem Speicher wird auch durch Budgets gesteuert, die für GitHub Actions oder die SKU „Actions Cache Storage“ festgelegt wurden. Wenn Sie Grenzwerte konfiguriert haben und ein Budget überschreiten, wird Ihr Cache schreibgeschützt, bis Ihr Abrechnungsstatus geklärt ist oder Ihre Nutzung durch das Ablaufen oder explizite Löschen von Caches unter den kostenlosen Grenzwert von 10 GB fällt. Weitere Informationen zum Einrichten von Budgets finden Sie unter [Einrichten von Budgets zum Kontrollieren der Ausgaben für Produkte mit verbrauchseinheitenbasierter Abrechnung](/de/enterprise-cloud@latest/billing/how-tos/set-up-budgets).\n\nWenn Sie die SKU-Budgets für den Actions-Cache-Speicher niedriger festlegen als die Gesamtkosten für die Nutzung Ihres konfigurierten Speichers während Ihres Abrechnungszeitraums, kann dies dazu führen, dass Ihr Cache häufig in den Lesezugriffsmodus wechselt. Wenn Ihr Budget für die SKU beispielsweise 0 $ beträgt und Sie die maximale Cachegröße Ihres Repositorys mit 20 GB konfiguriert haben, wechselt Ihr Cache in den schreibgeschützten Modus, sobald der Speicher den kostenlosen Schwellenwert überschreitet.\n\nNachfolgend finden Sie einige beispielhafte monatliche Kosten, die Ihnen bei der Budgetplanung für die Actions Cache Storage SKU helfen sollen.\n\n| Cachegröße | Monatliche Kosten (sofern vollständig genutzt) |\n| ---------- | ---------------------------------------------- |\n| 50 GB      | $2,80                                          |\n| 200 GB     | $ 13,30                                        |\n| 1000 GB    | $69,30                                         |\n\n## Nächste Schritte\n\nInformationen zum Verwalten von Abhängigkeitscaches findest du unter [Verwalten von Caches](/de/enterprise-cloud@latest/actions/how-tos/manage-workflow-runs/manage-caches)."}