Pipelinezwischenspeicherung

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. Das Zwischenspeichern ist besonders in Szenarien hilfreich, in denen dieselben Abhängigkeiten zu Beginn jeder Ausführung immer wieder heruntergeladen werden. Dies ist oft ein zeitaufwendiger Prozess mit Hunderten oder Tausenden von Netzwerkaufrufen.

Die Zwischenspeicherung kann zur Verbesserung der Buildzeit wirksam sein, vorausgesetzt, die Zeit zum Wiederherstellen und Speichern des Caches ist geringer als die Zeit, die Ausgabe von Grund auf neu zu erzeugen. Aus diesem Grund ist Zwischenspeicherung möglicherweise nicht in allen Szenarien wirksam und kann tatsächlich negative Auswirkungen auf die Buildzeit haben.

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 Dateien 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).

Cacheaufgabe: Funktionsweise

Das Zwischenspeichern wird einer Pipeline mithilfe der Cacheaufgabe hinzugefügt. Diese Aufgabe arbeitet wie jede andere Aufgabe und wird dem Abschnitt steps eines Jobs 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.

Konfigurieren der Cacheaufgabe

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

• Pfad: 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.

• 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 wird.

• Zeichenfolgen:
  Fester Wert (wie der Name des Caches oder eines Toolnamens) oder der aus einer Umgebungsvariable entnommen wurde (wie das aktuelle Betriebssystem oder der aktuelle Auftragsname)

• Dateipfade:
  Pfad zu einer bestimmten Datei, deren Inhalt gehasht wird. Diese Datei muss zum Zeitpunkt der Ausführung der Aufgabe 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 mit doppelten Anführungszeichen um, 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

Die Inhalte aller Dateien, die durch einen Dateipfad oder ein Dateimuster identifiziert werden, werden gehasht, um einen dynamischen Cache-Schlüssel zu erzeugen. Dies ist nützlich, wenn Ihr Projekt Dateien enthält, 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 mit $(System.DefaultWorkingDirectory)aufgelöst.

Beispiel:

Hier ist ein Beispiel, das zeigt, wie Abhängigkeiten zwischengespeichert werden, die von Yarn installiert wurden:

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, 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 in $(Pipeline.Workspace)/s/.yarn 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.

Wiederherstellen von Schlüsseln

restoreKeys kann verwendet werden, wenn man eine Abfrage nach mehreren genauen Schlüsseln oder Schlüsselpräfixen durchführen möchte. Dabei wird auf einen anderen Schlüssel zurückgegriffen, falls key keinen Treffer ergibt. Ein Wiederherstellungsschlüssel sucht nach einem Schlüssel anhand des Präfixes und liefert den neuesten erstellten Cacheeintrag als Ergebnis. Dies ist nützlich, wenn die Pipeline keine genaue Übereinstimmung finden kann, sondern stattdessen einen teilweisen Cachetreffer verwenden möchte. Wenn Sie mehrere Wiederherstellungsschlüssel einfügen möchten, trennen Sie sie mithilfe einer neuen Zeile, um den Wiederherstellungsschlüssel anzugeben (weitere Details finden Sie im Beispiel). Die Reihenfolge, mit der Wiederherstellungsschlüssel getestet werden, verläuft von oben nach unten.

Erforderliche Software auf dem selbstgehosteten Agent

Die oben genannten ausführbaren Dateien müssen sich in einem Ordner befinden, der in der PATH-Umgebungsvariable aufgeführt ist. 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 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 suchen, ob der Schlüssel im Cache vorhanden ist. Wenn der Schlüssel nicht im Cache 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 old-yarn.lock einen anderen Hash als yarn.lock ergab, generiert der Wiederherstellungsschlüssel einen Teiltreffer. 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.

Cache-Isolation 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 Folgendes sicherstellt:

1. Ein Auftrag aus einer Pipeline kann nicht auf die Caches aus einer anderen Pipeline zugreifen und
2. ein PR-Erstellungsauftrag hat 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 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 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 Details finden Sie weiter unten.

CI, manuelle und geplante Ausführungen

Pull Request-Ausführungen

Pull Request-Forkausführungen

Konditionierung bei Cachewiederherstellung

In einigen Szenarien sollte die erfolgreiche Wiederherstellung des Caches dazu führen, dass eine andere Gruppe von Schritten ausgeführt wird. Beispielsweise kann ein Schritt, der Abhängigkeiten installiert, ü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 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

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 Compiler-Cache 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). Setzen Sie die CCACHE_DIR-Umgebungsvariable auf einen Pfad unterhalb von $(Pipeline.Workspace) und cachen Sie dieses Verzeichnis.

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'))

• Schlüssel: (erforderlich) – ein eindeutiger Bezeichner für den Cache.
• Pfad: (erforderlich) – Pfad des Ordners oder der Datei, den 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 die Stelle fest, an der 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)

Maven

Maven hat ein lokales Repository, in dem es Downloads und erstellte Artefakte speichert. Um zu aktivieren, setzen Sie die Option maven.repo.local auf einen Pfad innerhalb von $(Pipeline.Workspace) und cachen Sie diesen Ordner.

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-Aufgabeverwenden, stellen Sie sicher, dass Sie auch die Variable MAVEN_OPTS übergeben, sonst wird sie überschrieben.

- 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 über eine packages.lock.json Datei verfügen, können Sie die Zwischenspeicherung aktivieren, indem Sie die NUGET_PACKAGES Umgebungsvariable auf einen Pfad unter $(UserProfile) festlegen und dieses Verzeichnis zwischenspeichern. Weitere Informationen zum Sperren von Abhängigkeiten finden Sie unter der Paketreferenz in den Projektdateien. Wenn Sie mehrere packages.lock.jsonverwenden möchten, können Sie das folgende Beispiel weiterhin verwenden, ohne Änderungen vorzunehmen. Der Inhalt aller packages.lock.json Dateien wird hashed 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

Dieser Ansatz gilt auch für .NET Core-Projekte, wenn Ihr Projekt packages.lock.json zum Sperren von Paketversionen verwendet. Sie können dies aktivieren, indem Sie RestorePackagesWithLockFile zu True in Ihrer Csproj-Datei ändern oder den folgenden Befehl verwenden: dotnet restore --use-lock-file.

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 an die öffentliche npm-Registrierung oder an eine private 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 nicht über eine package-lock.json Datei verfügt, verweisen Sie stattdessen in der Cacheschlüsseleingabe auf die package.json Datei.

Node.js/Yarn

Wie bei npm gibt es verschiedene Möglichkeiten zum Zwischenspeichern von Paketen, die mit Yarn installiert sind. 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. Bei der Installation überprüft Yarn dieses Verzeichnis zuerst (standardmäßig) auf Module, wodurch Netzwerkanrufe an öffentliche oder private 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 COMPOSER_CACHE_DIRUmgebungsvariable.

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.

F&A

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 ein Limit 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.