Pijplijncache

Azure DevOps Services-

Pijplijncaching kan helpen om de buildtijd te verminderen door de uitvoer of gedownloade afhankelijkheden van één uitvoering opnieuw te gebruiken in latere uitvoeringen, waardoor de kosten voor het opnieuw maken of opnieuw downloaden van dezelfde bestanden worden voorkomen. Caching is vooral handig in scenario's waarbij dezelfde afhankelijkheden aan het begin van elke uitvoering worden gedownload. Dit is vaak een tijdrovend proces waarbij honderden of duizenden netwerkoproepen worden gebruikt.

Caching kan effectief zijn bij het verbeteren van de buildtijd, mits de tijd die nodig is om de cache te herstellen, korter is dan de tijd om de uitvoer opnieuw te produceren. Hierdoor is caching in alle scenario's mogelijk niet effectief en kan dit in feite een negatieve invloed hebben op de bouwtijd.

Notitie

Pijplijncache wordt niet ondersteund in klassieke release-pijplijnen.

Wanneer gebruikt u artefacten in plaats van caching

Pijplijncaching en pijplijnartefacten vergelijkbare functies uitvoeren, maar zijn ontworpen voor verschillende scenario's en mogen niet door elkaar worden gebruikt.

• Pijplijnartefacten gebruiken wanneer u specifieke bestanden moet nemen die in de ene taak zijn geproduceerd en deze met andere taken wilt delen (en deze andere taken mislukken waarschijnlijk zonder deze).

• Gebruik pijplijncaching wanneer u de buildtijd wilt verbeteren door bestanden uit eerdere uitvoeringen opnieuw te gebruiken (en het ontbreken van deze bestanden heeft geen invloed op het vermogen van de taak om te worden uitgevoerd).

Notitie

Pijplijncaching en pijplijnartefacten zijn gratis voor alle niveaus (gratis en betaald). Zie Opslagverbruik van artefacten voor meer informatie.

Cachetaak: hoe deze werkt

Caching wordt toegevoegd aan een pijplijn met behulp van de Cache-taak. Deze taak werkt net als elke andere taak en wordt toegevoegd aan de sectie steps van een taak.

Wanneer er een cachestap wordt aangetroffen tijdens een uitvoering, wordt de cache hersteld op basis van de opgegeven invoer. Als er geen cache wordt gevonden, wordt de stap voltooid en wordt de volgende stap in de taak uitgevoerd.

Nadat alle stappen in de taak zijn uitgevoerd en ervan uitgaande dat er een geslaagde taakstatus is, wordt er automatisch een speciale 'Post-job: Cache' stap toegevoegd en geactiveerd voor elke 'herstelcache' stap die niet is overgeslagen. Deze stap is verantwoordelijk voor het opslaan van de cache.

Notitie

Caches zijn onveranderbaar, wat betekent dat wanneer een cache is gemaakt, de inhoud ervan niet kan worden gewijzigd.

De cachetaak configureren

De cachetaak heeft twee vereiste argumenten: sleutel en pad:

• pad: het pad van de map die in de cache moet worden opgeslagen. Dit kan een absoluut of een relatief pad zijn. Relatieve paden worden geëvalueerd ten opzichte van $(System.DefaultWorkingDirectory).

Notitie

U kunt vooraf gedefinieerde variabelen gebruiken om het pad op te slaan naar de map die u wilt opslaan, maar jokertekens worden niet ondersteund.

• sleutel: moet worden ingesteld op de id voor de cache die u wilt herstellen of opslaan. Sleutels bestaan uit een combinatie van tekenreekswaarden, bestandspaden of bestandspatronen, waarbij elk segment wordt gescheiden door een | teken.

• tekenreeksen:
  Vaste waarde (zoals de naam van de cache of de naam van een hulpprogramma) of afkomstig uit een omgevingsvariabele (zoals het huidige besturingssysteem of de naam van de huidige taak)

• bestandspaden:
  Pad naar een specifiek bestand waarvan de inhoud wordt gehasht. Dit bestand moet bestaan op het moment dat de taak wordt uitgevoerd. Houd er rekening mee dat elk sleutelsegment dat eruitziet als een bestandspad, wordt behandeld als een bestandspad. Dit omvat met name segmenten met een .. Dit kan ertoe leiden dat de taak mislukt wanneer dit 'bestand' niet bestaat.

  Tip

  Als u wilt voorkomen dat een padachtig tekenreekssegment wordt behandeld als een bestandspad, verpakt u het met dubbele aanhalingstekens, bijvoorbeeld: "my.key" | $(Agent.OS) | key.file

• bestandspatronen:
  Door komma's gescheiden lijst met jokertekens in glob-stijl die moeten overeenkomen met ten minste één bestand. Bijvoorbeeld:

  • **/yarn.lock: alle yarn.lock-bestanden onder de bronmap
  • */asset.json, !bin/**: alle asset.json bestanden in een map onder de map bronnen, met uitzondering van de bin-map

De inhoud van een bestand dat wordt geïdentificeerd door een bestandspad of bestandspatroon, wordt gehasht om een dynamische cachesleutel te produceren. Dit is handig wanneer uw project bestanden bevat die uniek bepalen wat er in de cache wordt opgeslagen. Zo worden bestanden zoals package-lock.json, yarn.lock, Gemfile.lockof Pipfile.lock vaak in een cachesleutel genoemd, omdat ze allemaal een unieke set afhankelijkheden vertegenwoordigen.

Relatieve bestandspaden of bestandspatronen worden opgelost op basis van $(System.DefaultWorkingDirectory).

voorbeeld van:

Hier volgt een voorbeeld van het opslaan van afhankelijkheden die door Yarn zijn geïnstalleerd:

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 dit voorbeeld bevat de cachesleutel drie delen: een statische tekenreeks ("yarn"), het besturingssysteem waarop de taak wordt uitgevoerd, omdat deze cache uniek is per besturingssysteem en de hash van het yarn.lock-bestand dat de set afhankelijkheden in de cache uniek identificeert.

Bij de eerste uitvoering nadat de taak is toegevoegd, rapporteert de stap van de cache een "cache miss" omdat de cache die met deze sleutel is geïdentificeerd, niet bestaat. Na de laatste stap wordt een cache gemaakt op basis van de bestanden in $(Pipeline.Workspace)/s/.yarn en geüpload. Tijdens de volgende uitvoering rapporteert de cachestap een 'cachetreffer' en wordt de inhoud van de cache gedownload en hersteld.

Wanneer u checkout: selfgebruikt, wordt de opslagplaats uitgecheckt naar $(Pipeline.Workspace)/sen bevindt de map .yarn zich meestal in de opslagplaats zelf.

Notitie

Pipeline.Workspace is het lokale pad op de agent waarop uw pijplijn wordt uitgevoerd, waar alle directories worden gemaakt. Deze variabele heeft dezelfde waarde als Agent.BuildDirectory.

Zorg ervoor dat u de variabele YARN_CACHE_FOLDER bijwerkt als u iets anders dan checkout: self gebruikt. Dit moet verwijzen naar de opslagplaats waar .yarn zich bevindt.

Sleutels herstellen

restoreKeys kan worden gebruikt als u een query wilt uitvoeren op meerdere exacte sleutels of sleutelvoorvoegsels. Dit wordt gebruikt om terug te vallen op een andere sleutel in het geval dat een key geen hit oplevert. Met een herstelsleutel wordt naar een sleutel gezocht op voorvoegsel en wordt de meest recente cachevermelding als resultaat gegeven. Dit is handig als de pijplijn geen exacte overeenkomst kan vinden, maar ervoor kiest een gedeeltelijke cachetreffer te gebruiken. Als u meerdere herstelsleutels wilt invoegen, moet u deze scheiden met behulp van een nieuwe regel om de herstelsleutel aan te geven (zie het voorbeeld voor meer informatie). De volgorde waarin herstelsleutels worden geprobeerd, is van boven naar beneden.

Vereiste software op zelf-gehoste agent

Software/platform archiveren	Ramen	Linux	Mac
GNU Tar	Vereist	Vereist	Nee
BSD Tar	Nee	Nee	Vereist
7-Zip	Aanbevolen	Nee	Nee

De bovenstaande uitvoerbare bestanden moeten zich in een map bevinden die wordt vermeld in de omgevingsvariabele PATH. Houd er rekening mee dat de gehoste agents bij de software zijn inbegrepen. Dit is alleen van toepassing op zelf-hostende agents.

voorbeeld van:

Hier volgt een voorbeeld van het gebruik van herstelsleutels door 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 dit voorbeeld probeert de cachetaak te achterhalen of de sleutel in de cache bestaat. Als de sleutel niet in de cache bestaat, wordt geprobeerd de eerste herstelsleutel te gebruiken yarn | $(Agent.OS). Hiermee wordt gezocht naar alle sleutels die exact overeenkomen met die sleutel of die sleutel als voorvoegsel hebben. Een prefix hit kan optreden als er een ander yarn.lock hash-segment is. Als de volgende sleutel yarn | $(Agent.OS) | old-yarn.lock zich bijvoorbeeld in de cache bevindt waar de old-yarn.lock een andere hash dan yarn.lockheeft opgeleverd, zou de herstelsleutel een gedeeltelijke hit opleveren. Als de eerste herstelsleutel ontbreekt, wordt vervolgens de volgende herstelsleutel gebruikt yarn waarmee wordt geprobeerd een sleutel te vinden die begint met yarn. Voor voorvoegseltreffers levert het resultaat de laatst gemaakte cachesleutel op als resultaat.

Notitie

Een pijplijn kan een of meer cachetaken hebben. Er is geen limiet voor de cache-opslagcapaciteit, en zowel jobs als taken uit dezelfde pijplijn kunnen toegang krijgen tot en gebruikmaken van dezelfde cache.

Isolatie en beveiliging van cache

Om isolatie tussen caches van verschillende pijplijnen en verschillende vertakkingen te garanderen, behoort elke cache tot een logische container die een 'scope' wordt genoemd. Scopes bieden een beveiligingsgrens die ervoor zorgt dat:

1. Een taak van één pijplijn heeft geen toegang tot de caches van een andere pijplijn en
2. Een taak die een pull-aanvraag bouwt, heeft leestoegang tot de caches voor de doelbranch van de pull-aanvraag (voor dezelfde pijplijn), maar kan geen caches schrijven (maken) in het bereik van de doelbranch.

Wanneer er tijdens een uitvoering een cachestap wordt aangetroffen, wordt de cache die door de sleutel wordt geïdentificeerd, aangevraagd bij de server. De server zoekt vervolgens naar een cache met deze sleutel in de scopes die zichtbaar zijn voor de taak en retourneert de cache (indien beschikbaar). Bij het opslaan van de cache (aan het einde van de taak) wordt een cache naar het bereik geschreven dat de pijplijn en vertakking vertegenwoordigt. Zie hieronder voor meer informatie.

CI, handmatige en geplande runs

Draagwijdte	Lezen	Schrijven
Brontak	Ja	Ja
main vertakking	Ja	Nee
master vertakking	Ja	Nee

Pull-aanvraaguitvoeringen

Draagwijdte	Lezen	Schrijven
Bronvertakking	Ja	Nee
De doelvertakking	Ja	Nee
Tussenliggende vertakking (zoals refs/pull/1/merge)	Ja	Ja
main vertakking	Ja	Nee
master vertakking	Ja	Nee

Uitvoeringen van pull-aanvraagfork

Tak	Lezen	Schrijven
Doelvestiging	Ja	Nee
Tussenliggende vertakking (zoals refs/pull/1/merge)	Ja	Ja
main vertakking	Ja	Nee
master vertakking	Ja	Nee

Fooi

Omdat caches al zijn afgestemd op een project, pijplijn en vertakking, hoeft u geen project-, pijplijn- of vertakkings-id's op te nemen in de cachesleutel.

Voorwaarden bij cacheherstel

In sommige scenario's moet de geslaagde herstelbewerking van de cache ertoe leiden dat een andere reeks stappen wordt uitgevoerd. Een stap waarmee afhankelijkheden worden geïnstalleerd, kan bijvoorbeeld worden overgeslagen als de cache is hersteld. Dit is mogelijk met behulp van de cacheHitVar taakinvoer. Als u deze invoer instelt op de naam van een omgevingsvariabele, wordt de variabele ingesteld op true wanneer er een cache-hit is, inexact op een herstelsleutelcache, anders is deze ingesteld op false. Deze variabele kan vervolgens worden verwezen in een stapvoorwaarde of vanuit een script.

In het volgende voorbeeld wordt de install-deps.sh stap overgeslagen wanneer de cache wordt hersteld:

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

Voor Ruby-projecten die Bundler gebruiken, moet u de BUNDLE_PATH-omgevingsvariabele overschrijven die Bundler gebruikt om het -pad in te stellen waarin Bundler naar Gems zoekt.

voorbeeld van:

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- is een compilercache voor C/C++. Als u Ccache in uw pijplijn wilt gebruiken, moet u ervoor zorgen dat Ccache is geïnstalleerd en optioneel is toegevoegd aan uw PATH (zie Ccache-uitvoeringsmodi). Stel de omgevingsvariabele CCACHE_DIR in op een pad onder $(Pipeline.Workspace) en sla deze map in de cache op.

voorbeeld van:

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

Zie configuratie-instellingen voor Ccache voor meer informatie.

Docker-installatiekopieën

Door Docker-images te cachen, wordt de tijd die nodig is om uw pijplijn uit te voeren drastisch verminderd.

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

• sleutel: (vereist) - een unieke id voor de cache.
• pad: (vereist) - pad van de map of het bestand dat u wilt cachen.

Golang

Voor Golang-projecten kunt u opgeven welke pakketten moeten worden gedownload in het bestand go.mod. Als uw GOCACHE variabele nog niet is ingesteld, stelt u deze in op de locatie waar u de cache wilt downloaden.

voorbeeld van:

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

Het gebruik van de ingebouwde cachingondersteuning van Gradle kan een aanzienlijke invloed hebben op de buildtijd. Als u de buildcache wilt inschakelen, stelt u de omgevingsvariabele GRADLE_USER_HOME in op een pad onder $(Pipeline.Workspace) en voert u de build uit met --build-cache of voegt u org.gradle.caching=true toe aan uw gradle.properties-bestand.

voorbeeld van:

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: de terugvalsleutels als de primaire sleutel mislukt (optioneel)

Notitie

Caches zijn onveranderbaar, zodra een cache met een bepaalde sleutel is gemaakt voor een specifiek bereik (vertakking), kan de cache niet worden bijgewerkt. Dit betekent dat als de sleutel een vaste waarde is, alle volgende builds voor dezelfde vertakking de cache niet kunnen bijwerken, zelfs niet als de inhoud van de cache is gewijzigd. Als u een vaste-sleutelwaarde wilt gebruiken, moet u het argument restoreKeys gebruiken als een terugvaloptie.

Maven

Maven heeft een lokale opslagplaats waarin downloads en gebouwde artefacten worden opgeslagen. Als u dit wilt inschakelen, stelt u de optie maven.repo.local in op een pad onder $(Pipeline.Workspace) en slaat u deze map in de cache op.

voorbeeld van:

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

Als u de Maven-taakgebruikt, moet u ook de variabele MAVEN_OPTS doorgeven omdat deze anders wordt overschreven.

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

.NET/NuGet

Als u PackageReferences gebruikt om NuGet-afhankelijkheden rechtstreeks in uw projectbestand te beheren en een packages.lock.json-bestand te hebben, kunt u caching inschakelen door de omgevingsvariabele NUGET_PACKAGES in te stellen op een pad onder $(UserProfile) en deze map in de cache op te slaan. Zie Pakketreferentie in projectbestanden voor meer informatie over het vergrendelen van afhankelijkheden. Als u meerdere packages.lock.jsonwilt gebruiken, kunt u nog steeds het volgende voorbeeld gebruiken zonder wijzigingen aan te brengen. De inhoud van alle packages.lock.json bestanden wordt gehasht en als een van de bestanden wordt gewijzigd, wordt er een nieuwe cachesleutel gegenereerd.

voorbeeld van:

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

Deze methode is ook geldig voor .NET Core-projecten als uw project gebruikmaakt van packages.lock.json om pakketversies te vergrendelen. U kunt dit inschakelen door RestorePackagesWithLockFile in te stellen op True in uw Csproj-bestand of door de volgende opdracht te gebruiken: dotnet restore --use-lock-file.

Node.js/npm

Er zijn verschillende manieren om caching in te schakelen in een Node.js project, maar de aanbevolen manier is om npm's gedeelde cachemapop te cachen. Deze map wordt beheerd door npm en bevat een in de cache opgeslagen versie van alle gedownloade modules. Tijdens de installatie controleert npm deze map eerst (standaard) op modules die netwerkoproepen naar het openbare NPM-register of een privéregister kunnen verminderen of elimineren.

Omdat het standaardpad naar de gedeelde cachemap van NPM niet hetzelfde is op alle platforms, is het raadzaam om de omgevingsvariabele npm_config_cache te overschrijven naar een pad onder $(Pipeline.Workspace). Dit zorgt er ook voor dat de cache toegankelijk is vanuit container- en niet-containertaken.

voorbeeld van:

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

Als uw project geen package-lock.json bestand heeft, raadpleegt u in plaats daarvan het package.json bestand in de invoer van de cachesleutel.

Tip

Omdat npm ci de map node_modules verwijdert om ervoor te zorgen dat een consistente, herhaalbare set modules wordt gebruikt, moet u voorkomen dat node_modules in de cache worden opgeslagen bij het aanroepen van npm ci.

Node.js/Yarn

Net als bij npm zijn er verschillende manieren om pakketten op te cachen die zijn geïnstalleerd met Yarn. De aanbevolen manier is om de gedeelde cachemap van Yarnop te cachen. Deze map wordt beheerd door Yarn en bevat een in de cache opgeslagen versie van alle gedownloade pakketten. Tijdens de installatie controleert Yarn deze map eerst (standaard) op modules, waardoor netwerkaanroepen naar openbare of privéregisters kunnen worden beperkt of verwijderd.

voorbeeld van:

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

Uw pijplijncache instellen met Anaconda-omgevingen:

Voorbeeld

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

Voor PHP-projecten die Composer gebruiken, overschrijft u de omgevingsvariabele COMPOSER_CACHE_DIR gebruikt door Composer.

voorbeeld van:

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

Bekende problemen en feedback

Als u kwesties ondervindt met het instellen van caching voor uw pijplijn, kijk naar de lijst met geopende kwesties in de microsoft/azure-pipelines-tasks repository. Als het probleem niet wordt vermeld, een nieuwe maken en de benodigde informatie over uw scenario opgeven.

Q&A

Kan ik een cache wissen?

A: Het wissen van een cache wordt momenteel niet ondersteund. U kunt echter een letterlijke tekenreeks (zoals version2) toevoegen aan uw bestaande cachesleutel om te voorkomen dat bestaande caches worden geraakt. Wijzig bijvoorbeeld de volgende cachesleutel van deze:

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

Naar dit:

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

V: Wanneer verloopt een cache?

A: Caches verlopen na zeven dagen zonder activiteit.

V: Wanneer wordt de cache geüpload?

A: Na de laatste stap van uw pijplijn wordt er een cache gemaakt op basis van uw cache path en geüpload. Zie het voorbeeld voor meer informatie.

V: Is er een limiet voor de grootte van een cache?

A: Er is geen afgedwongen limiet voor de grootte van afzonderlijke caches of de totale grootte van alle caches in een organisatie.