Pipelinezwischenspeicherung

Azure DevOps Services

Die Pipelinespeicherung kann dazu beitragen, die Erstellungszeit zu verringern, indem die Ausgaben oder heruntergeladenen Abhängigkeiten von einer Ausführung in späteren Ausführung wiederverwendet werden können, wodurch die Kosten reduziert oder vermieden werden, um die gleichen Dateien erneut zu erstellen oder erneut herunterzuladen. Das Zwischenspeichern ist besonders nützlich in Szenarien, in denen die gleichen Abhängigkeiten am Anfang jeder Ausführung heruntergeladen werden. Dies ist häufig ein zeitaufwendiger Prozess mit Hunderten oder Tausenden von Netzwerkaufrufen.

Das Zwischenspeichern kann wirksam sein, um die Buildzeit zu verbessern, sofern die Zeit zum Wiederherstellen und Speichern des Caches kleiner ist als die Zeit, um die Ausgabe erneut von Grund auf zu erzeugen. Aus diesem Grunde kann die Zwischenspeicherung in allen Szenarien nicht wirksam sein und kann tatsächlich negative Auswirkungen auf die Buildzeit haben.

Das Zwischenspeichern wird derzeit in CI- und Bereitstellungsaufträgen unterstützt, aber nicht klassische Releaseaufträge.

Wann Artefakte im Vergleich zum Zwischenspeichern verwendet werden sollen

Pipelinecache - und Pipelineartefakte führen ähnliche Funktionen aus, sind jedoch für unterschiedliche Szenarien ausgelegt und sollten nicht austauschbar verwendet werden. Im Allgemeinen:

• Verwenden Sie Pipelineartefakte , wenn Sie bestimmte Dateien in einem Auftrag erstellen und diese mit anderen Aufträgen teilen müssen (und diese anderen Aufträge werden wahrscheinlich ohne sie fehlschlagen).

• Verwenden Sie das Zwischenspeichern der Pipeline , wenn Sie die Erstellungszeit verbessern möchten, indem Sie Dateien aus früheren Ausführungen erneut verwenden (und diese Dateien haben keine Auswirkungen auf die Ausführung des Auftrags).

Hinweis

Das Zwischenspeichern ist derzeit kostenlos, und Caches werden in Azure Blob Storage gespeichert.

Cacheaufgabe

Das Zwischenspeichern wird einer Pipeline mithilfe der Cache Pipelineaufgabe 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 aufgetreten ist, wird der Cache basierend auf den bereitgestellten Eingaben wiederhergestellt. Wenn kein Cache gefunden wird, wird der Schritt abgeschlossen und der nächste Schritt im Auftrag ausgeführt. Nachdem alle Schritte im Auftrag ausgeführt wurden und ein erfolgreicher Auftragsstatus angenommen wird, wird ein spezieller "Speichercache"-Schritt für jeden "Wiederherstellungscache"-Schritt ausgeführt, der nicht übersprungen wurde. Dieser Schritt ist für das Speichern des Caches verantwortlich.

Hinweis

Caches sind unveränderlich, d. h. wenn ein Cache erstellt wurde, kann der Inhalt nicht mehr geändert werden.

Konfigurieren der Cacheaufgabe

Die Cacheaufgabe weist zwei erforderliche Argumente auf: Schlüssel und Pfad:

• pfad: der Pfad des zu zwischenspeichernden Ordners. Kann ein absoluter oder ein relativer Pfad sein. Relative Pfade werden gegen $(System.DefaultWorkingDirectory).

Hinweis

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

• schlüssel: 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 wird.

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

• Dateipfade:
  Pfad zu einer bestimmten Datei, deren Inhalt hashed wird. Diese Datei muss zum Zeitpunkt der Ausführung der Aufgabe vorhanden sein. Beachten Sie, dass ein beliebiges Schlüsselsegment, das "wie ein Dateipfad aussieht" wie ein Dateipfad behandelt wird. Dies schließt insbesondere Segmente ein, die ein .. 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 mit doppelten Anführungszeichen um, z. B.: "my.key" | $(Agent.OS) | key.file

• Dateimuster:
  Durch Trennzeichen getrennte Liste des Wildcardmusters im Glob-Stil, das mindestens einer Datei entsprechen muss. 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, außer unter dem Bin-Verzeichnis

Der Inhalt einer datei, die durch einen Dateipfad oder ein Dateimuster identifiziert wird, wird hashed, um einen dynamischen Cacheschlüssel zu erzeugen. Dies ist nützlich, wenn Ihr Projekt über Dateien verfügt, die eindeutig identifizieren, was zwischengespeichert wird. Beispielsweise werden Dateien wie package-lock.json, yarn.lock, , Gemfile.lockoder Pipfile.lock häufig in einem Cacheschlüssel referenziert, da sie alle einen eindeutigen Satz von Abhängigkeiten darstellen.

Relative Dateipfade oder Dateimuster werden gegen $(System.DefaultWorkingDirectory).

Beispiel:

Im folgenden Beispiel wird gezeigt, wie Abhängigkeiten zwischengespeichert werden, die von Yarn installiert sind:

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 enthält der Cacheschlüssel drei Teile: eine statische Zeichenfolge ("Yarn"), das Betriebssystem, auf dem der Auftrag ausgeführt wird, da dieser Cache pro Betriebssystem eindeutig ist, und der Hash der yarn.lock Datei, die den Satz von Abhängigkeiten im Cache eindeutig identifiziert.

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

Wiederherstellen von Schlüsseln

restoreKeys kann verwendet werden, wenn man mehrere genaue Schlüssel oder Schlüsselpräfixe abfragen möchte. Dies wird verwendet, um auf einen anderen Schlüssel zurückzugreifen, wenn ein key Treffer nicht erzielt wird. Ein Wiederherstellungsschlüssel sucht nach einem Schlüssel nach Präfix und gibt den neuesten erstellten Cacheeintrag als Ergebnis 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 einfach mithilfe einer neuen Zeile, um den Wiederherstellungsschlüssel anzugeben (weitere Details finden Sie im Beispiel). Die Reihenfolge, an der Schlüssel wiederhergestellt werden sollen, werden von oben nach unten ausgeführt.

Erforderliche Software für selbst gehosteten Agent

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

Die obigen ausführbaren Dateien müssen sich in einem Ordner befinden, der in der PATH-Umgebungsvariable aufgeführt ist. Bitte beachten Sie, dass die gehosteten Agents mit der enthaltenen Software geliefert werden, dies gilt nur für selbst gehostete Agents.

Beispiel:

Hier sehen Sie ein Beispiel für die Verwendung von Wiederherstellungsschlüsseln durch 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 suchen, ob der Schlüssel im Cache vorhanden ist. Wenn der Schlüssel im Cache nicht vorhanden ist, versucht er, den ersten Wiederherstellungsschlüssel yarn | $(Agent.OS)zu verwenden. Dadurch wird versucht, nach allen Schlüsseln zu suchen, die dem Schlüssel genau entsprechen oder diesen Schlüssel als Präfix aufweisen. 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 der alte yarn.lock einen anderen Hash yarn.lockals zurückgegeben hat, führt der Wiederherstellungsschlüssel zu einem Teiltreffer. Wenn der erste Wiederherstellungsschlüssel fehlkommt, wird der nächste Wiederherstellungsschlüssel yarn verwendet, der versucht, einen schlüssel zu finden, der mit dem Ersten beginnt yarn. Bei Präfixtreffern wird das Ergebnis den zuletzt erstellten Cacheschlüssel als Ergebnis erhalten.

Hinweis

Eine Pipeline kann eine oder mehrere Zwischenspeicheraufgaben aufweisen. Es gibt keinen Grenzwert für die Zwischenspeicherkapazität, und Aufträge und Aufgaben aus derselben Pipeline können auf denselben Cache zugreifen und gemeinsam nutzen.

Cacheisolation und Sicherheit

Um die Isolation zwischen Caches aus unterschiedlichen Pipelines und verschiedenen 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, und ein Auftrag, der ein PR erstellt, hat Lesezugriff auf die Caches für die Zielzweige der PR (für dieselbe Pipeline), kann aber keine Caches im Bereich der Zielzweige schreiben (erstellen).

Wenn während einer Ausführung ein Cacheschritt auftritt, wird der vom 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 gibt den Cache (sofern verfügbar) zurück. Beim Speichern des Caches (am Ende des Auftrags) wird ein Cache in den Bereich geschrieben, der die Pipeline und verzweigt darstellt. Weitere Informationen finden Sie unten.

CI, manuelle und geplante Ausführung

Bereich	Lesen	Schreiben
Quellzweig	Ja	Ja
main-Branch	Ja	Nein

Pullanforderungsausführungen

Bereich	Lesen	Schreiben
Quellzweig	Ja	Nein
Zielzweig	Ja	Nein
Zwischenzweig (z. B refs/pull/1/merge. )	Ja	Ja
main-Branch	Ja	Nein

Pullanforderungs-Freihandausführungen

Verzweigung	Lesen	Schreiben
Zielzweig	Ja	Nein
Zwischenzweig (z. B refs/pull/1/merge. )	Ja	Ja
main-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 einbezogen werden.

Konditionierung bei der Cachewiederherstellung

In einigen Szenarien sollte die erfolgreiche Wiederherstellung des Caches dazu führen, dass eine andere Reihe von Schritten ausgeführt wird. Beispielsweise kann ein Schritt, in dem Abhängigkeiten installiert werden, ü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 festgelegt, wenn ein Cachetreffer vorhanden true ist, inexact andernfalls wird die Variable auf einen Wiederherstellungsschlüsselcachetreffer festgelegt false. Auf diese Variable kann dann in einer Schrittbedingung oder aus einem Skript verwiesen werden.

Im folgenden Beispiel wird der install-deps.sh Schritt übersprungen, wenn der Cache wiederhergestellt wird:

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

Für Ruby-Projekte mit Bundler überschreiben Sie die Umgebungsvariable, die BUNDLE_PATH von Bundler verwendet wird, um den Pfad-Bundler festzulegen, sucht nach Gems in.

Beispiel:

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

steps:
- task: Cache@2
  inputs:
    key: 'gems | "$(Agent.OS)" | my.gemspec'
    restoreKeys: | 
      gems | "$(Agent.OS)"
      gems
    path: $(BUNDLE_PATH)
  displayName: Cache gems

- script: bundle install

Ccache (C/C++)

Ccache ist ein Compilercache für C/C++. Um Ccache in Ihrer Pipeline zu verwenden, stellen Sie sicher, dass Ccache sie installiert ist und optional zu Ihrem PATH Hinzugefügt wird (siehe Ccache-Ausführungsmodi). Legen Sie die CCACHE_DIR Umgebungsvariable auf einen Pfad unter $(Pipeline.Workspace) , 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
  inputs:
    key: 'ccache | "$(Agent.OS)"'
    path: $(CCACHE_DIR)
    restoreKeys: | 
      ccache | "$(Agent.OS)"
  displayName: ccache

Weitere Informationen finden Sie unter Ccache-Konfigurationseinstellungen .

Docker-Images

Das Zwischenspeichern von Docker-Images verringert die Zeit, mit der Ihre Pipeline ausgeführt werden muss.

pool:
  vmImage: 'Ubuntu-18.04'
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'))

  - script: |
      mkdir -p $(Pipeline.Workspace)/docker
      docker save -o $(Pipeline.Workspace)/docker/cache.tar cache
    displayName: Docker save
    condition: and(not(canceled()), or(failed(), ne(variables.CACHE_RESTORED, 'true')))

• schlüssel: (erforderlich) – ein eindeutiger Bezeichner für den Cache.
• Pfad: (erforderlich) – Pfad des Ordners oder der Datei, den Sie zwischenspeichern möchten.

Golang

Bei Golang-Projekten können Sie die Pakete angeben, die in der Go.mod-Datei heruntergeladen werden sollen. Wenn Ihre GOCACHE Variable noch nicht festgelegt ist, legen Sie sie fest, wo 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 integrierte Zwischenspeicherungsunterstützung von Gradle kann erhebliche Auswirkungen auf die Buildzeit haben. Um den Buildcache zu aktivieren, legen Sie die GRADLE_USER_HOME Umgebungsvariable auf einen Pfad unter$(Pipeline.Workspace), und führen Sie entweder Ihren Build aus--build-cache, oder fügen Sie sie Ihrer gradle.properties Datei hinzuorg.gradle.caching=true.

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: Build

• 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 (Branch) erstellt wird, kann der Cache nicht aktualisiert werden. Dies bedeutet, dass, wenn der Schlüssel ein fester Wert ist, alle nachfolgenden Builds für dieselbe Verzweigung nicht in der Lage sein, 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 integrierte Artefakte gespeichert werden. Legen Sie zum Aktivieren die maven.repo.local Option auf einen Pfad unter $(Pipeline.Workspace) und zwischenspeichern Sie diesen Ordner fest.

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@3
  inputs:
    mavenPomFile: 'pom.xml'
    mavenOptions: '-Xmx3072m $(MAVEN_OPTS)'

.NET/NuGet

Wenn Sie NuGet Abhängigkeiten direkt in Ihrer Projektdatei verwalten und über eine packages.lock.json Datei verfügen, können Sie die Zwischenspeicherung aktivieren, indem Sie PackageReferences die NUGET_PACKAGES Umgebungsvariable auf einen Pfad unter $(UserProfile) und zwischenspeichern dieses Verzeichnis festlegen. Weitere Informationen zum Sperren von Abhängigkeiten finden Sie unter "Paketreferenz" in Projektdateien .

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 des Zwischenspeicherns in einem Node.js Projekt, aber die empfohlene Möglichkeit 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 an die öffentliche npm-Registrierung oder eine private Registrierung reduzieren oder beseitigen können.

Da der Standardpfad zum freigegebenen Npm-Cacheverzeichnis nicht auf allen Plattformen identisch ist, empfiehlt es sich, die npm_config_cache Umgebungsvariable in einen Pfad zu $(Pipeline.Workspace)überschreiben. Dadurch wird sichergestellt, dass der Cache von Container- und Nicht-Containeraufträgen zugänglich 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 Datei enthält package-lock.json , verweisen Sie stattdessen auf die package.json Datei in der Cacheschlüsseleingabe.

Tipp

Da npm ci der node_modules Ordner gelöscht wird, um sicherzustellen, dass ein konsistenter, wiederholbarer Satz von Modulen verwendet wird, sollten Sie beim Aufrufen die Zwischenspeicherung node_modulesnpm civermeiden.

Node.js/Yarn

Wie bei npm gibt es verschiedene Möglichkeiten, Pakete zwischenzuspeichern, die mit Yarn installiert sind. Die empfohlene Möglichkeit besteht darin, den freigegebenen Cacheordner von Yarn zwischenzuspeichern. 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) für Module, die Netzwerkaufrufe an öffentliche oder private Registrierungen reduzieren oder beseitigen 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 Pipelinespeicherung 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

- 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

Für PHP-Projekte mit Composer überschreiben Sie die Umgebungsvariable, die COMPOSER_CACHE_DIR von Composer verwendet wird.

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 geöffneten Probleme im microsoft/azure-pipelines-tasks Repo. Wenn Ihr Problem nicht aufgeführt ist, erstellen Sie ein neues, und geben Sie die erforderlichen Informationen zu Ihrem Szenario an.

F&A

F: Kann ich einen Cache löschen?

A: Das Löschen eines Caches wird derzeit nicht unterstützt. Sie können jedoch einen Zeichenfolgen literal (z version2. B. ) zu Ihrem vorhandenen Cacheschlüssel hinzufügen, um den Schlüssel so zu ändern, dass alle Treffer auf vorhandenen Caches vermieden werden. Ändern Sie beispielsweise den folgenden Cacheschlüssel aus diesem Beispiel:

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

in:

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: Gibt es ein Limit für die Größe eines Caches?

A: Es gibt kein erzwungenes Limit für die Größe einzelner Caches oder die Gesamtgröße aller Caches in einer Organisation.