Freigeben über

Pipelinezwischenspeicherung

  • Artikel

Azure DevOps Services

Die Pipelinezwischenspeicherung kann zum Verkürzen der Erstellungszeit hilfreich sein. Dabei können die Ausgaben oder heruntergeladenen Abhängigkeiten einer Ausführung in späteren Ausführungen wiederverwendet werden, wodurch die Kosten für das erneute Erstellen oder Herunterladen derselben Dateien verringert oder vermieden werden. Die Zwischenspeicherung ist besonders in Szenarien nützlich, in denen dieselben Abhängigkeiten zu Beginn jeder Ausführung immer wieder heruntergeladen werden. Dies ist oft ein zeitaufwändiger Prozess mit mehreren hundert oder tausend Netzwerkaufrufen.

Die Zwischenspeicherung bei der Verbesserung der Buildzeit effektiv sein, vorausgesetzt, die Zeit zum Wiederherstellen und Speichern des Caches ist kürzer als die Zeit, um die Ausgabe von Grund auf neu zu erstellen. Aus diesem Grunde ist die Zwischenspeicherung möglicherweise nicht in allen Szenarien effektiv und kann sich sogar negativ auf die Buildzeit auswirken.

Hinweis

Die Pipelinezwischenspeicherung wird in Agentpoolaufträgen sowohl für YAML-Pipelines als auch für klassische Pipelines unterstützt. Sie wird jedoch nicht in klassischen Releasepipelines unterstützt.

Verwendung von Artefakten im Vergleich zum Zwischenspeichern

Pipelinezwischenspeicherung und Pipelineartefakte führen ähnliche Funktionen aus, sind jedoch für unterschiedliche Szenarien konzipiert und sollten nicht austauschbar verwendet werden.

  • Verwenden Sie Pipelineartefakte, wenn Sie bestimmte Dateien, die in einem Auftrag generiert wurden, für andere Aufträge freigeben müssen (und diese anderen Aufträge ohne diese Dateieen wahrscheinlich fehlschlagen werden).

  • Verwenden Sie die Pipelinezwischenspeicherung, wenn Sie die Buildzeit verbessern möchten, indem Sie Dateien aus früheren Ausführungen wiederverwenden (und das Nichtvorhandensein dieser Dateien sich nicht auf die Ausführungsfähigkeit des Auftrags auswirkt).

Hinweis

Für die Pipelinezwischenspeicherung und Pipelineartefakte fallen bei allen Tarifen (kostenlos und kostenpflichtig) keine Kosten an. Weitere Einzelheiten dazu finden Sie unter Artefaktspeichernutzung.

Cacheaufgabe: Funktionsweise

Das Zwischenspeichern wird einer Pipeline mithilfe der Cacheaufgabe hinzugefügt. Diese Aufgabe funktioniert wie jede andere Aufgabe und wird dem steps-Abschnitt eines Auftrags hinzugefügt.

Wenn während einer Ausführung ein Cacheschritt auftritt, stellt die Aufgabe den Cache basierend auf den bereitgestellten Eingaben wieder her. Wenn kein Cache gefunden werden kann, wird der Schritt abgeschlossen, und der nächste Schritt im Auftrag wird ausgeführt.

Nachdem alle Schritte im Auftrag ausgeführt wurden und der Auftragsstatus erfolgreich lautet, wird automatisch ein spezieller Schritt „Post-Auftrag: Cache“ hinzugefügt und für jeden nicht übersprungenen Schritt „Cache wiederherstellen“ ausgelöst. Dieser Schritt ist für das Speichern des Caches verantwortlich.

Hinweis

Caches sind unveränderlich, was bedeutet, dass nach der Erstellung eines Caches der Inhalt nicht mehr geändert werden kann.

Cacheaufgabe konfigurieren

Die Cacheaufgabe weist zwei erforderliche Argumente auf: key und path:

  • path: Der Pfad des Ordners, der zwischengespeichert werden soll. Dies kann ein absoluter oder relativer Pfad sein. Relative Pfade werden für $(System.DefaultWorkingDirectory)aufgelöst.

Hinweis

Sie können vordefinierte Variablen verwenden, um den Pfad zu dem Ordner zu speichern, den Sie zwischenspeichern möchten. Platzhalter werden jedoch nicht unterstützt.

  • key: Diese Einstellung sollte auf den Bezeichner für den Cache festgelegt werden, den Sie wiederherstellen oder speichern möchten. Schlüssel bestehen aus einer Kombination aus Zeichenfolgenwerten, Dateipfaden oder Dateimustern, wobei jedes Segment durch ein |-Zeichen getrennt ist.

  • Zeichenfolgen:
    Fester Wert (z. B. der Name des Caches oder eines Toolnamens) oder aus einer Umgebungsvariable (z. B. aus dem aktuellen Betriebssystem oder dem aktuellen Auftragsnamen)

  • Dateipfade:
    Pfad zu einer bestimmten Datei, deren Inhalt gehasht wird. Diese Datei muss zum Zeitpunkt der Aufgabenausführung vorhanden sein. Beachten Sie, dass jedes Schlüsselsegment, das „wie ein Dateipfad aussieht“, wie ein Dateipfad behandelt wird. Dies betrifft insbesondere Segmente, die ein .enthalten. Dies kann dazu führen, dass die Aufgabe fehlschlägt, wenn diese „Datei“ nicht vorhanden ist.

    Tipp

    Um zu vermeiden, dass ein pfadähnliches Zeichenfolgensegment wie ein Dateipfad behandelt wird, schließen Sie es in doppelte Anführungszeichen ein, z. B.: "my.key" | $(Agent.OS) | key.file

  • Dateimuster:
    Durch Komma getrennte Liste im Glob-Stil-Platzhaltermuster, die mindestens mit einer Datei übereinstimmen müssen. Beispiel:

    • **/yarn.lock: alle yarn.lock-Dateien unter dem Quellverzeichnis
    • */asset.json, !bin/**: alle asset.json-Dateien, die sich in einem Verzeichnis unter dem Quellverzeichnis befinden, mit Ausnahme des bin-Verzeichnisses

Der Inhalt von durch einen Dateipfad oder ein Dateimuster identifizierten Dateien wird gehasht, um einen dynamischen Cacheschlüssel zu erzeugen. Dies ist hilfreich, wenn Ihr Projekt über Dateien verfügt, die die zwischengespeicherten Inhalte eindeutig identifizieren. Beispielsweise werden Dateien wie package-lock.json, yarn.lock, Gemfile.lock oder Pipfile.lock häufig in einem Cacheschlüssel referenziert, da sie alle einen eindeutigen Satz von Abhängigkeiten darstellen.

Relative Dateipfade oder Dateimuster werden mit $(System.DefaultWorkingDirectory)aufgelöst.

Beispiel:

Das folgende Beispiel zeigt, wie Sie von Yarn installierte Abhängigkeiten zwischenspeichern:

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/s/.yarn

steps:
- task: Cache@2
  inputs:
    key: '"yarn" | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       "yarn" | "$(Agent.OS)"
       "yarn"
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

In diesem Beispiel enthält der Cacheschlüssel drei Teile: eine statische Zeichenfolge („yarn“), das Betriebssystem, unter dem der Auftrag ausgeführt wird, da dieser Cache pro Betriebssystem eindeutig ist, und den Hash der yarn.lock-Datei, der die Abhängigkeiten im Cache eindeutig identifiziert.

Bei der ersten Ausführung nach dem Hinzufügen der Aufgabe meldet der Cacheschritt einen „Cachefehlversuch“, da der durch diesen Schlüssel identifizierte Cache nicht vorhanden ist. Nach dem letzten Schritt wird aus den Dateien in $(Pipeline.Workspace)/s/.yarn ein Cache erstellt und hochgeladen. Bei der nächsten Ausführung meldet der Cacheschritt einen „Cachetreffer“, und der Inhalt des Caches wird heruntergeladen und wiederhergestellt.

Bei der Verwendung von checkout: self wird das Repository nach $(Pipeline.Workspace)/s ausgecheckt, und Ihr .yarn-Ordner befindet sich normalerweise im Repository selbst.

Hinweis

Pipeline.Workspace ist der lokale Pfad auf dem Agent, der Ihre Pipeline ausführt, in dem alle Verzeichnisse erstellt werden. Diese Variable hat denselben Wert wie Agent.BuildDirectory.

Stellen Sie sicher, dass Sie die Variable YARN_CACHE_FOLDER aktualisieren, wenn Sie etwas anderes als checkout: self verwenden, da diese auf das Repository verweisen sollte, in dem sich .yarn befindet.

Schlüssel wiederherstellen

restoreKeys kann verwendet werden, wenn mehrere exakte Schlüssel oder Schlüsselpräfixe abgefragt werden sollen. Dabei wird auf einen anderen Schlüssel zurückgegriffen, falls key keinen Treffer ergibt. Ein Wiederherstellungsschlüssel sucht per Präfix nach einem Schlüssel und gibt als Ergebnis den zuletzt erstellten Cacheeintrag zurück. Dies ist nützlich, wenn die Pipeline keine genaue Übereinstimmung finden kann, sondern stattdessen einen teilweisen Cachetreffer verwenden möchte. Um mehrere Wiederherstellungsschlüssel einzufügen, trennen Sie sie mithilfe einer neuen Zeile, um den Wiederherstellungsschlüssel anzugeben (weitere Einzelheiten finden Sie im Beispiel). Die Reihenfolge, mit der Wiederherstellungsschlüssel getestet werden, verläuft von oben nach unten.

Erforderliche Software auf dem selbstgehosteten Agent

Archivsoftware/Plattform Windows Linux Mac
GNU Tar Erforderlich Erforderlich Nein
BSD Tar Nein Nein Erforderlich
7-Zip Empfohlen Nein Nein

Die oben genannten ausführbaren Dateien müssen sich in einem Ordner befinden, der in der Umgebungsvariable PATH aufgeführt ist. Beachten Sie, dass die gehosteten Agents mit der Software geliefert werden. Dies gilt nur für selbstgehostete Agents.

Beispiel:

Hier sehen Sie ein Beispiel für die Verwendung von Wiederherstellungsschlüsseln von Yarn:

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/.yarn

steps:
- task: Cache@2
  inputs:
    key: '"yarn" | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       yarn | "$(Agent.OS)"
       yarn
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

In diesem Beispiel versucht die Cacheaufgabe zu ermitteln, ob der Schlüssel im Cache vorhanden ist. Wenn der Schlüssel nicht im Cache vorhanden ist, wird versucht, den ersten Wiederherstellungsschlüssel yarn | $(Agent.OS) zu verwenden. Dabei wird nach allen Schlüsseln gesucht, die entweder genau mit diesem Schlüssel übereinstimmen oder über diesen Schlüssel als Präfix verfügen. Ein Präfixtreffer kann auftreten, wenn ein anderes yarn.lock-Hashsegment vorhanden ist. Wenn sich beispielsweise der folgende Schlüssel yarn | $(Agent.OS) | old-yarn.lock im Cache befand, in dem old-yarn.lock einen anderen Hash als yarn.lock ergibt, wird dem Wiederherstellungsschlüssel ein Teiltreffer erzielt. Wenn der erste Wiederherstellungsschlüssel fehlt, wird der nächste Wiederherstellungsschlüssel yarn verwendet. Dieser sucht nach einem beliebigen Schlüssel, der mit yarn beginnt. Bei Präfixtreffern ergibt das Ergebnis den zuletzt erstellten Cacheschlüssel.

Hinweis

Eine Pipeline kann eine oder mehrere Cacheaufgaben aufweisen. Die Zwischenspeicherkapazität ist nicht begrenzt, und Aufträge und Aufgaben aus derselben Pipeline können auf denselben Cache zugreifen und ihn gemeinsam nutzen.

Cacheisolation und Sicherheit

Um die Isolation zwischen Caches aus verschiedenen Pipelines und unterschiedlichen Verzweigungen sicherzustellen, gehört jeder Cache zu einem logischen Container, der als Bereich bezeichnet wird. Bereiche bieten eine Sicherheitsgrenze, die sicherstellt, dass ein Auftrag aus einer Pipeline nicht auf die Caches aus einer anderen Pipeline zugreifen kann. Zudem hat ein PR-Erstellungsauftrag Lesezugriff auf die Caches für die PR-Zielverzweigung (für dieselbe Pipeline), er kann aber keine Caches im Bereich der Zielverzweigung schreiben (erstellen).

Wenn während einer Ausführung ein Cacheschritt auftritt, wird der durch den Schlüssel identifizierte Cache vom Server angefordert. Der Server sucht dann nach einem Cache mit diesem Schlüssel aus den Bereichen, die für den Auftrag sichtbar sind, und er gibt den Cache zurück (sofern verfügbar). Beim Speichern des Caches (am Ende des Auftrags) wird ein Cache in den Bereich geschrieben, der die Pipeline und die Verzweigung darstellt. Weitere Informationen finden Sie unten.

CI, manuelle und geplante Ausführungen

`Scope` Lesen Schreiben
Quellverzweigung Ja Ja
main Branch Ja No
master Branch Ja Nein

Pull Request-Ausführungen

`Scope` Lesen Schreiben
Quellverzweigung Ja Nein
Zielverzweigung Ja Nein
Zwischenverzweigung (z. B refs/pull/1/merge) Ja Ja
main Branch Ja No
master Branch Ja Nein

Pull Request-Forkausführungen

Branch Lesen Schreiben
Zielverzweigung Ja Nein
Zwischenverzweigung (z. B refs/pull/1/merge) Ja Ja
main Branch Ja No
master Branch Ja Nein

Tipp

Da Caches bereits auf ein Projekt, eine Pipeline und eine Verzweigung festgelegt sind, müssen keine Projekt-, Pipeline- oder Verzweigungsbezeichner in den Cacheschlüssel eingefügt werden.

Konditionierung bei Cachewiederherstellung

In einigen Szenarien sollte die erfolgreiche Wiederherstellung des Caches dazu führen, dass verschiedene Schritte ausgeführt werden. Beispielsweise kann ein Schritt zum Installieren von Abhängigkeiten übersprungen werden, wenn der Cache wiederhergestellt wurde. Dies ist mithilfe der cacheHitVar-Aufgabeneingabe möglich. Wenn Sie diese Eingabe auf den Namen einer Umgebungsvariable festlegen, wird die Variable bei einem Cachetreffer auf true und bei einem Wiederherstellungsschlüssel-Cachetreffer auf inexact festgelegt. Andernfalls wird sie auf false festgelegt. Auf diese Variable kann dann in einer Schrittbedingung oder aus einem Skript verwiesen werden.

Im folgenden Beispiel wird beim Wiederherstellen des Cache der install-deps.sh-Schritt übersprungen:

steps:
- task: Cache@2
  inputs:
    key: mykey | mylockfile
    restoreKeys: mykey
    path: $(Pipeline.Workspace)/mycache
    cacheHitVar: CACHE_RESTORED

- script: install-deps.sh
  condition: ne(variables.CACHE_RESTORED, 'true')

- script: build.sh

Bundler

Bei Ruby-Projekten mit Bundler überschreiben Sie die von Bundler verwendete BUNDLE_PATH-Umgebungsvariable, um den Pfad festzulegen, unter dem Bundler nach Gems sucht.

Beispiel:

variables:
  BUNDLE_PATH: $(Pipeline.Workspace)/.bundle

steps:
- task: Cache@2
  displayName: Bundler caching
  inputs:
    key: 'gems | "$(Agent.OS)" | Gemfile.lock'
    path: $(BUNDLE_PATH)
    restoreKeys: | 
      gems | "$(Agent.OS)"
      gems

Ccache (C/C++)

Ccache ist ein Compilercache für C/C++. Um Ccache in Ihrer Pipeline zu verwenden, stellen Sie sicher, dass Ccache installiert ist und optional zu PATH hinzugefügt wird (siehe Ccache-Ausführungsmodi). Legen Sie dieCCACHE_DIR-Umgebungsvariable auf einen Pfad unter $(Pipeline.Workspace) fest, und speichern Sie dieses Verzeichnis zwischen.

Beispiel:

variables:
  CCACHE_DIR: $(Pipeline.Workspace)/ccache

steps:
- bash: |
    sudo apt-get install ccache -y    
    echo "##vso[task.prependpath]/usr/lib/ccache"
  displayName: Install ccache and update PATH to use linked versions of gcc, cc, etc

- task: Cache@2
  displayName: Ccache caching
  inputs:
    key: 'ccache | "$(Agent.OS)" | $(Build.SourceVersion)'
    path: $(CCACHE_DIR)
    restoreKeys: | 
      ccache | "$(Agent.OS)"

Weitere Einzelheiten finden Sie unter Ccache-Konfigurationseinstellungen.

Docker-Images

Durch das Zwischenspeichern von Docker-Images wird die zum Ausführen der Pipeline benötigte Zeit erheblich reduziert.

variables:
  repository: 'myDockerImage'
  dockerfilePath: '$(Build.SourcesDirectory)/app/Dockerfile'
  tag: '$(Build.BuildId)'

pool:
  vmImage: 'ubuntu-latest'
steps:
  - task: Cache@2
    displayName: Cache task
    inputs:
      key: 'docker | "$(Agent.OS)" | cache'
      path: $(Pipeline.Workspace)/docker
      cacheHitVar: CACHE_RESTORED                #Variable to set to 'true' when the cache is restored
    
  - script: |
      docker load -i $(Pipeline.Workspace)/docker/cache.tar
    displayName: Docker restore
    condition: and(not(canceled()), eq(variables.CACHE_RESTORED, 'true'))

  - task: Docker@2
    displayName: 'Build Docker'
    inputs:
      command: 'build'
      repository: '$(repository)'
      dockerfile: '$(dockerfilePath)'
      tags: |
        '$(tag)'

  - script: |
      mkdir -p $(Pipeline.Workspace)/docker
      docker save -o $(Pipeline.Workspace)/docker/cache.tar $(repository):$(tag)
    displayName: Docker save
    condition: and(not(canceled()), not(failed()), ne(variables.CACHE_RESTORED, 'true'))
  • key: (erforderlich) – ein eindeutiger Bezeichner für den Cache.
  • path: (erforderlich) – Pfad des Ordners oder der Datei, die sie zwischenspeichern möchten.

Golang

Für Golang-Projekte können Sie die Pakete angeben, die in der Datei go.mod heruntergeladen werden sollen. Wenn Ihre GOCACHE-Variable noch nicht festgelegt ist, legen Sie sie auf den Speicherort fest, an dem der Cache heruntergeladen werden soll.

Beispiel:

variables:
  GO_CACHE_DIR: $(Pipeline.Workspace)/.cache/go-build/

steps:
- task: Cache@2
  inputs:
    key: 'go | "$(Agent.OS)" | go.mod'
    restoreKeys: | 
      go | "$(Agent.OS)"
    path: $(GO_CACHE_DIR)
  displayName: Cache GO packages

Gradle

Die Verwendung der integrierten Cacheunterstützung von Gradle kann sich erheblich auf die Buildzeit auswirken. Um den Buildcache zu aktivieren, legen Sie die GRADLE_USER_HOME-Umgebungsvariable auf einen Pfad unter $(Pipeline.Workspace) fest, und führen Sie den Build mit --build-cache aus, oder fügen Sie org.gradle.caching=true Ihrer gradle.properties-Datei hinzu.

Beispiel:

variables:
  GRADLE_USER_HOME: $(Pipeline.Workspace)/.gradle

steps:
- task: Cache@2
  inputs:
    key: 'gradle | "$(Agent.OS)" | **/build.gradle.kts' # Swap build.gradle.kts for build.gradle when using Groovy
    restoreKeys: |
      gradle | "$(Agent.OS)"
      gradle
    path: $(GRADLE_USER_HOME)
  displayName: Configure gradle caching

- task: Gradle@2
  inputs:
    gradleWrapperFile: 'gradlew'
    tasks: 'build'
    options: '--build-cache'
  displayName: Build

- script: |   
    # stop the Gradle daemon to ensure no files are left open (impacting the save cache operation later)
    ./gradlew --stop    
  displayName: Gradlew stop
  • restoreKeys: Die Fallbackschlüssel, wenn der Primärschlüssel fehlschlägt (optional)

Hinweis

Caches sind unveränderlich. Sobald ein Cache mit einem bestimmten Schlüssel für einen bestimmten Bereich (Verzweigung) erstellt wurde, kann der Cache nicht aktualisiert werden. Im Falle eines festen Schlüssels bedeutet dies, dass alle nachfolgenden Builds für dieselbe Verzweigung nicht in der Lage sind, den Cache zu aktualisieren, auch wenn sich der Inhalt des Caches geändert hat. Wenn Sie einen festen Schlüsselwert verwenden möchten, müssen Sie das restoreKeys-Argument als Fallbackoption verwenden.

Maven

Maven verfügt über ein lokales Repository, in dem Downloads und erstellte Artefakte gespeichert werden. Legen Sie zum Aktivieren die Option maven.repo.local auf einen Pfad unter $(Pipeline.Workspace) fest, und speichern Sie diesen Ordner zwischen.

Beispiel:

variables:
  MAVEN_CACHE_FOLDER: $(Pipeline.Workspace)/.m2/repository
  MAVEN_OPTS: '-Dmaven.repo.local=$(MAVEN_CACHE_FOLDER)'

steps:
- task: Cache@2
  inputs:
    key: 'maven | "$(Agent.OS)" | **/pom.xml'
    restoreKeys: |
      maven | "$(Agent.OS)"
      maven
    path: $(MAVEN_CACHE_FOLDER)
  displayName: Cache Maven local repo

- script: mvn install -B -e

Wenn Sie eine Maven-Aufgabe verwenden, müssen Sie auch die MAVEN_OPTS-Variable übergeben, da sie andernfalls überschrieben wird:

- task: Maven@4
  inputs:
    mavenPomFile: 'pom.xml'
    mavenOptions: '-Xmx3072m $(MAVEN_OPTS)'

.NET/NuGet

Wenn Sie PackageReferences verwenden, um NuGet-Abhängigkeiten direkt in Ihrer Projektdatei zu verwalten und Sie eine packages.lock.json-Datei haben, können Sie die Zwischenspeicherung aktivieren, indem Sie die NUGET_PACKAGES-Umgebungsvariable auf einen Pfad unter $(UserProfile) festlegen und dieses Verzeichnis zwischenspeichern. Weitere Einzelheiten zum Sperren von Abhängigkeiten finden Sie unter Paketreferenz in Projektdateien. Wenn Sie mehrere packages.lock.json-Dateien verwenden möchten, können Sie weiterhin das folgende Beispiel verwenden, ohne Änderungen vorzunehmen. Der Inhalt aller packages.lock.json-Dateien wird gehasht, und wenn eine der Dateien geändert wird, wird ein neuer Cacheschlüssel generiert.

Beispiel:

variables:
  NUGET_PACKAGES: $(Pipeline.Workspace)/.nuget/packages

steps:
- task: Cache@2
  inputs:
    key: 'nuget | "$(Agent.OS)" | $(Build.SourcesDirectory)/**/packages.lock.json'
    restoreKeys: |
       nuget | "$(Agent.OS)"
       nuget
    path: $(NUGET_PACKAGES)
  displayName: Cache NuGet packages

Node.js/npm

Es gibt verschiedene Möglichkeiten zum Aktivieren der Zwischenspeicherung in einem Node.js-Projekt, aber die empfohlene Methode besteht darin, das freigegebene Cacheverzeichnis von npm zwischenzuspeichern. Dieses Verzeichnis wird von npm verwaltet und enthält eine zwischengespeicherte Version aller heruntergeladenen Module. Während der Installation überprüft npm dieses Verzeichnis zuerst (standardmäßig) auf Module, die Netzwerkaufrufe der öffentlichen npm-Registrierung oder einer privaten Registrierung reduzieren oder beseitigen können.

Da der Standardpfad zum freigegebenen Cacheverzeichnis von npm nicht auf allen Plattformen identisch ist, wird empfohlen, die npm_config_cache-Umgebungsvariable in einen Pfad unter $(Pipeline.Workspace) zu überschreiben. Dadurch wird auch sichergestellt, dass der Zugriff auf den Cache von Container- und Nichtcontaineraufträgen aus möglich ist.

Beispiel:

variables:
  npm_config_cache: $(Pipeline.Workspace)/.npm

steps:
- task: Cache@2
  inputs:
    key: 'npm | "$(Agent.OS)" | package-lock.json'
    restoreKeys: |
       npm | "$(Agent.OS)"
    path: $(npm_config_cache)
  displayName: Cache npm

- script: npm ci

Wenn Ihr Projekt keine package-lock.json-Datei enthält, verweisen Sie stattdessen in der Cacheschlüsseleingabe auf die package.json-Datei.

Tipp

Da npm ci den node_modules-Ordner löscht, um sicherzustellen, dass ein konsistenter, wiederholbarer Satz von Modulen verwendet wird, sollten Sie die Zwischenspeicherung von node_modules beim Aufrufen von npm ci vermeiden.

Node.js/Yarn

Wie bei npm gibt es verschiedene Möglichkeiten zum Zwischenspeichern von mit Yarn installierten Paketen. Die empfohlene Methode ist das Zwischenspeichern des freigegebenen Cacheordners von Yarn. Dieses Verzeichnis wird von Yarn verwaltet und enthält eine zwischengespeicherte Version aller heruntergeladenen Pakete. Während der Installation überprüft Yarn dieses Verzeichnis zuerst (standardmäßig) auf Module, wodurch Netzwerkaufrufe von öffentlichen oder privaten Registrierungen reduziert oder beseitigt werden können.

Beispiel:

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/.yarn

steps:
- task: Cache@2
  inputs:
    key: 'yarn | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       yarn | "$(Agent.OS)"
       yarn
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

Python/Anaconda

Richten Sie Ihre Pipelinezwischenspeicherung mit Anaconda-Umgebungen ein:

Beispiel

variables:
  CONDA_CACHE_DIR: /usr/share/miniconda/envs

# Add conda to system path
steps:
- script: echo "##vso[task.prependpath]$CONDA/bin"
  displayName: Add conda to PATH

- bash: |
    sudo chown -R $(whoami):$(id -ng) $(CONDA_CACHE_DIR)
  displayName: Fix CONDA_CACHE_DIR directory permissions

- task: Cache@2
  displayName: Use cached Anaconda environment
  inputs:
    key: 'conda | "$(Agent.OS)" | environment.yml'
    restoreKeys: | 
      python | "$(Agent.OS)"
      python
    path: $(CONDA_CACHE_DIR)
    cacheHitVar: CONDA_CACHE_RESTORED

- script: conda env create --quiet --file environment.yml
  displayName: Create Anaconda environment
  condition: eq(variables.CONDA_CACHE_RESTORED, 'false')

  • Windows

    - task: Cache@2
  displayName: Cache Anaconda
  inputs:
    key: 'conda | "$(Agent.OS)" | environment.yml'
    restoreKeys: | 
      python | "$(Agent.OS)"
      python
    path: $(CONDA)/envs
    cacheHitVar: CONDA_CACHE_RESTORED

- script: conda env create --quiet --file environment.yml
  displayName: Create environment
  condition: eq(variables.CONDA_CACHE_RESTORED, 'false')

PHP/Composer

Überschreiben Sie bei PHP-Projekten mit Composer die von Composer verwendete Umgebungsvariable COMPOSER_CACHE_DIR.

Beispiel:

variables:
  COMPOSER_CACHE_DIR: $(Pipeline.Workspace)/.composer

steps:
- task: Cache@2
  inputs:
    key: 'composer | "$(Agent.OS)" | composer.lock'
    restoreKeys: |
      composer | "$(Agent.OS)"
      composer
    path: $(COMPOSER_CACHE_DIR)
  displayName: Cache composer

- script: composer install

Bekannte Probleme und Feedback

Wenn Probleme beim Einrichten der Zwischenspeicherung für Ihre Pipeline auftreten, überprüfen Sie die Liste der offenen Probleme im microsoft/azure-pipelines-tasks-Repository. Wenn Ihr Problem nicht aufgeführt wird, erstellen Sie ein neues Issue, und geben Sie die erforderlichen Informationen zu Ihrem Szenario an.

Fragen und Antworten

F: Kann ich einen Cache löschen?

A: Das Löschen eines Caches wird derzeit nicht unterstützt. Sie können jedoch Ihrem vorhandenen Cacheschlüssel ein Zeichenfolgenliteral hinzufügen (z. B. version2), um den Schlüssel so zu ändern, dass Treffer für vorhandene Caches vermieden werden. Ändern Sie beispielsweise den folgenden Cacheschlüssel von:

key: 'yarn | "$(Agent.OS)" | yarn.lock'

Folgendermaßen:

key: 'version2 | yarn | "$(Agent.OS)" | yarn.lock'

F: Wann läuft ein Cache ab?

A: Caches laufen nach sieben Tagen ohne Aktivität ab.

F: Wann wird der Cache hochgeladen?

A: Nach dem letzten Schritt Ihrer Pipeline wird ein Cache aus Ihrem Cache path erstellt und hochgeladen. Weitere Einzelheiten dazu finden Sie im Beispiel.

F: Gibt es eine Beschränkung für die Größe eines Caches?

A: Es gibt keine erzwungene Beschränkung für die Größe einzelner Caches oder die Gesamtgröße aller Caches in einer Organisation.