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 ondersteund in agentpooltaken voor zowel YAML- als klassieke pijplijnen. Het wordt echter niet ondersteund in klassieke release-pijplijnen.
Wanneer gebruikt u artefacten versus caching
Pijplijncaching en pijplijnartefacten voeren vergelijkbare functies uit, maar zijn ontworpen voor verschillende scenario's en mogen niet door elkaar worden gebruikt.
Gebruik pijplijnartefacten wanneer u specifieke bestanden moet nemen die in de ene taak zijn geproduceerd en deze delen met andere taken (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 deze bestanden hebben geen invloed op de mogelijkheid van de taak om uit te voeren).
Notitie
Pijplijncaching en pijplijnartefacten zijn gratis voor alle lagen (gratis en betaald). zie Het opslagverbruik van artefacten voor meer informatie.
Cachetaak: hoe deze werkt
Caching wordt toegevoegd aan een pijplijn met behulp van de cachetaak. Deze taak werkt net als elke andere taak en wordt toegevoegd aan de steps
sectie 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 de taakstatus is geslaagd, wordt automatisch een speciale stap 'Post-job: Cache' toegevoegd en geactiveerd voor elke stap 'herstelcache' die niet is overgeslagen. Deze stap is verantwoordelijk voor het opslaan van de cache.
Notitie
Caches zijn onveranderbaar, wat betekent dat nadat 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 opgelost tegen
$(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. Voorbeeld:**/yarn.lock
: alle yarn.lock-bestanden onder de map bronnen*/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. Bijvoorbeeld bestanden zoalspackage-lock.json
, yarn.lock
of Gemfile.lock
Pipfile.lock
worden vaak verwezen in een cachesleutel, omdat ze allemaal een unieke set afhankelijkheden vertegenwoordigen.
Relatieve bestandspaden of bestandspatronen worden opgelost op basis $(System.DefaultWorkingDirectory)
van .
Voorbeeld:
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 onderdelen: 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 cachestap een 'cachemisser' omdat de cache die door 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 de opslagplaats gebruikt checkout: self
, wordt deze uitgecheckt naar $(Pipeline.Workspace)/s
en bevindt uw .yarn
map zich meestal in de opslagplaats zelf.
Notitie
Pipeline.Workspace
is het lokale pad op de agent waarop uw pijplijn wordt uitgevoerd, waar alle mappen worden gemaakt. Deze variabele heeft dezelfde waarde als Agent.BuildDirectory
.
Zorg ervoor dat u de variabele YARN_CACHE_FOLDER
bijwerkt als u iets anders gebruikt dan checkout: self
dit moet verwijzen naar de opslagplaats waar .yarn
zich bevindt.
Sleutels herstellen
restoreKeys
kan worden gebruikt als u query's 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
hit niet 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 in plaats daarvan een gedeeltelijke cachetreffer wil 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-hostende agent
Software/platform archiveren | Windows | Linux | Mac |
---|---|---|---|
GNU Tar | Vereist | Vereist | Nee |
BSD Tar | Nee | Nee | Vereist |
7-Zip | Aanbevolen | Nee | Nr. |
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:
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 yarn | $(Agent.OS)
te gebruiken.
Hiermee wordt gezocht naar alle sleutels die exact overeenkomen met die sleutel of die sleutel als voorvoegsel hebben. Een voorvoegsel 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 bevond waar de old-yarn.lock
gegenereerde hash een andere hash heeft opgeleverd dan yarn.lock
, levert de herstelsleutel een gedeeltelijke hit op.
Als de eerste herstelsleutel ontbreekt, wordt vervolgens de volgende herstelsleutel yarn
gebruikt 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 cacheopslagcapaciteit en taken en taken uit dezelfde pijplijn hebben toegang tot en delen 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 bereik wordt genoemd. Bereiken bieden een beveiligingsgrens die ervoor zorgt dat een taak van de ene pijplijn geen toegang heeft tot de caches van een andere pijplijn en een taak die een pull-aanvraag bouwt, leestoegang heeft 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 uit de bereiken 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 hierna voor meer informatie.
CI, handmatige en geplande uitvoeringen
Bereik | Read | Write |
---|---|---|
Bronbranch | Ja | Ja |
main tak |
Ja | Nr. |
master tak |
Ja | Nr. |
Pull-aanvraaguitvoeringen
Bereik | Read | Write |
---|---|---|
Bronbranch | Ja | Nr. |
Doelbranch | Ja | Nr. |
Tussenliggende vertakking (zoals refs/pull/1/merge ) |
Ja | Ja |
main tak |
Ja | Nr. |
master tak |
Ja | Nr. |
Uitvoeringen van pull-aanvraagfork
Vertakking | Read | Write |
---|---|---|
Doelbranch | Ja | Nr. |
Tussenliggende vertakking (zoals refs/pull/1/merge ) |
Ja | Ja |
main tak |
Ja | Nr. |
master tak |
Ja | Nr. |
Tip
Omdat caches al zijn gericht op een project, pijplijn en vertakking, hoeft u geen project-, pijplijn- of vertakkings-id's op te nemen in de cachesleutel.
Conditionering bij herstel van cache
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, inexact
wordt de variabele ingesteld true
op wanneer er sprake is van een cache- of herstelsleutelcache, anders is deze ingesteld false
op . 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, overschrijft u de BUNDLE_PATH
omgevingsvariabele die door Bundler wordt gebruikt om het pad Bundler in te stellen op Gems.
Voorbeeld:
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
deze is geïnstalleerd en optioneel is toegevoegd aan uw PATH
(zie Ccache-uitvoeringsmodi). Stel de CCACHE_DIR
omgevingsvariabele in op een pad onder $(Pipeline.Workspace)
deze map en cache.
Voorbeeld:
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 Ccache-configuratie-instellingen voor meer informatie.
Docker-installatiekopieën
Het opslaan van Docker-installatiekopieën in de cache vermindert de tijd die nodig is om uw pijplijn uit te voeren.
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: (vereist) - een unieke id voor de cache.
- pad: (vereist) - pad van de map of het bestand dat u wilt opslaan.
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:
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 ondersteuning voor caching van Gradle kan een aanzienlijke invloed hebben op de buildtijd. Als u de buildcache wilt inschakelen, stelt u de GRADLE_USER_HOME
omgevingsvariabele in op een pad onder $(Pipeline.Workspace)
en voert u de build uit met --build-cache
of voegt u deze toe org.gradle.caching=true
aan uw gradle.properties
bestand.
Voorbeeld:
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 restoreKeys
argument 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 maven.repo.local
optie in op een pad onder $(Pipeline.Workspace)
en slaat u deze map in de cache op.
Voorbeeld:
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 een Maven-taak gebruikt, moet u ook de MAVEN_OPTS
variabele doorgeven omdat deze anders wordt overschreven:
- task: Maven@4
inputs:
mavenPomFile: 'pom.xml'
mavenOptions: '-Xmx3072m $(MAVEN_OPTS)'
.NET/NuGet
Als u NuGet-afhankelijkheden PackageReferences
rechtstreeks in uw projectbestand beheert en een packages.lock.json
bestand hebt, kunt u caching inschakelen door de NUGET_PACKAGES
omgevingsvariabele 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.json wilt 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:
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
Er zijn verschillende manieren om caching in te schakelen in een Node.js-project, maar de aanbevolen manier is om de gedeelde cachemap van NPM op 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 npm_config_cache
omgevingsvariabele te overschrijven naar een pad onder $(Pipeline.Workspace)
. Dit zorgt er ook voor dat de cache toegankelijk is vanuit container- en niet-containertaken.
Voorbeeld:
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 bestand heeft package-lock.json
, verwijst u in plaats daarvan naar het package.json
bestand in de invoer van de cachesleutel.
Tip
Omdat npm ci
de node_modules
map wordt verwijderd om ervoor te zorgen dat een consistente, herhaalbare set modules wordt gebruikt, moet u caching node_modules
voorkomen bij het aanroepen 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 Yarn op 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:
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:
Opmerking
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 COMPOSER_CACHE_DIR
omgevingsvariabele die door Composer wordt gebruikt.
Voorbeeld:
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 problemen ondervindt bij het instellen van caching voor uw pijplijn, controleert u de lijst met geopende problemen in de microsoft/azure-pipelines-tasks opslagplaats. Als uw probleem niet wordt weergegeven, maakt u een nieuw probleem en geeft u de benodigde informatie op over uw scenario.
V&A
V: 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 de sleutel zodanig te wijzigen dat er geen treffers optreden in bestaande caches. Wijzig bijvoorbeeld de volgende cachesleutel van deze:
key: 'yarn | "$(Agent.OS)" | yarn.lock'
Ga als volgt te werk:
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.