Pipeline-cache

2025-04-30

Azure DevOps-tjänster

Cachelagring av pipelinen kan minska byggtiden genom att återanvända nedladdade beroenden från tidigare körningar, så att du inte behöver återskapa eller ladda ned samma filer igen. Detta är särskilt användbart i scenarier där samma beroenden laddas ned upprepade gånger i början av varje körning. Det här är ofta en tidskrävande process som omfattar hundratals eller tusentals nätverksanrop.

Cachelagring är mest effektivt när den tid som krävs för att återställa och spara cacheminnet är mindre än den tid det tar att återskapa filerna. Men i vissa fall kanske cachelagring inte ger prestandafördelar och kan till och med påverka byggtiden negativt. Det är viktigt att utvärdera ditt specifika scenario för att avgöra om cachelagring är rätt metod.

Obs

Cachelagring av pipeline stöds inte för klassiska versionspipelines.

När du ska använda pipelineartefakter kontra pipelinecachelagring

Cachelagring av pipeline och pipelineartefakter utför liknande funktioner men är avsedda för olika scenarier och bör inte användas på ett utbytbart sätt.

Använd pipelineartefakter: när du behöver ta specifika filer som skapats av ett jobb och dela dem med andra jobb (och de andra jobben skulle förmodligen misslyckas utan dem).
Använd pipeline-cachning: när du vill förbättra byggtiden genom att återanvända filer från tidigare körningar, eftersom frånvaron av dessa filer inte påverkar jobbets förmåga att köras.

Obs

Pipeline-cache och pipeline-artifakter är tillgängliga utan kostnad för alla nivåer (kostnadsfri och betald). Mer information finns i Artifakternas lagringsförbrukning.

Krav för lokalt installerad agent

Följande körbara filer måste finnas i en mapp som anges i PATH miljövariabeln. Observera att dessa krav endast gäller för lokalt installerade agenter, eftersom värdbaserade agenter förinstalleras med nödvändig programvara.

Arkivera programvara/plattform	Windows	Linux	Mac
GNU Tjära	Krävs	Krävs	Nej
BSD tar	Nej	Nej	Krävs
7-dragkedja	Rekommenderad	Nej	Nej

Cacheaktivitet: Så här fungerar den

Cachelagring läggs till i en pipeline genom att cacheaktiviteten läggs till i steps avsnittet i ett jobb.

När ett cachesteg påträffas under pipelinekörningen försöker uppgiften återställa cachen baserat på de angivna indata. Om ingen cache hittas slutförs steget och nästa steg i jobbet körs.

När alla steg i jobbet har körts framgångsrikt läggs ett särskilt "Post-job: Cache" -steg automatiskt till och utlöses för varje "återställningscache"-steg som inte har hoppats över. Det här steget har ansvar för att spara cacheminnet .

Obs

Cacher är oföränderliga. När en cache har skapats kan dess innehåll inte ändras.

Konfigurera cachningsuppgiften

Cacheaktiviteten har två obligatoriska argument: sökväg och nyckel:

path: Sökvägen till den mapp som du vill cachelagrade. Detta kan vara en absolut eller relativ sökväg. Relativa sökvägar löses upp mot $(System.DefaultWorkingDirectory).

Tips

Du kan använda fördefinierade variabler för att lagra sökvägen till den mapp som du vill cachelagrar. Jokertecken stöds dock inte.
nyckel: Detta definierar identifieraren för cacheminnet som du vill återställa eller spara. Nyckeln består av en kombination av strängvärden, filsökvägar eller filmönster, där varje segment avgränsas med ett | tecken.
- Strängar:
  Ett fast värde (till exempel cachenamnet eller ett verktygsnamn) eller hämtat från en miljövariabel (till exempel det aktuella operativsystemet eller jobbnamnet).
- Filsökvägar:
  Sökvägen till en specifik fil vars innehåll ska hashas. Filen måste finnas när aktiviteten körs. Alla segment som liknar en filsökväg behandlas som sådana, så var försiktig, särskilt när du använder segment som innehåller ., eftersom detta kan leda till "filen finns inte" fel.
  
  Tips
  
  Om du vill undvika att ett sökvägsliknande strängsegment behandlas som en filsökväg, omsluter du det med dubbla citattecken, till exempel: "my.key" | $(Agent.OS) | key.file
- Filmönster:
  En kommaavgränsad lista över jokerteckenmönster i globformat som måste matcha minst en fil. Exempel:
  - **/yarn.lock: alla yarn.lock-filer under källkatalogen.
  - */asset.json, !bin/**: alla asset.json filer som finns i en katalog under källkatalogen, förutom de i bin-katalogen .

Innehållet i en fil som identifieras av en filsökväg eller ett filmönster hashas för att generera en dynamisk cachenyckel. Detta är användbart när projektet har filer som unikt identifierar vad som cachelagras. Till exempel refereras filer som package-lock.json, yarn.lock, Gemfile.lockeller Pipfile.lock ofta i en cachenyckel, eftersom de representerar en unik uppsättning beroenden. Relativa filsökvägar eller mönster löses utifrån $(System.DefaultWorkingDirectory).

Exempel:

I följande exempel visas hur du cachelagrade Yarn-paket:

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

I det här exemplet består cachenyckeln av tre delar: en statisk sträng ("yarn"), operativsystemet som jobbet körs på (eftersom cachen är unik per operativsystem) och hashen för yarn.lock filen (som unikt identifierar beroendena).

Vid den första körningen efter att uppgiften har lagts till rapporterar cachesteget en "cachemiss" eftersom cachen som identifieras av den här nyckeln inte finns. Efter det sista steget skapas en cache från filerna i $(Pipeline.Workspace)/s/.yarn och laddas upp. Vid nästa körning rapporterar cachesteget en "cacheträff" och innehållet i cachen laddas ned och återställs.

När du använder checkout: selfcheckas lagringsplatsen ut till $(Pipeline.Workspace)/soch mappen .yarn kommer troligen att finnas på själva lagringsplatsen.

Obs

Pipeline.Workspace är den lokala sökvägen på agenten som kör din pipeline där alla kataloger skapas. Den här variabeln har samma värde som Agent.BuildDirectory. Om du inte använder checkout: self, kontrollerar du att du uppdaterar variabeln YARN_CACHE_FOLDER så att den pekar på platsen för .yarn i ditt lagringsutrymme.

Använd återställningsnycklar

restoreKeys gör att du kan ställa frågor till flera specifika nycklar eller nyckelprefix. Den används som reserv när den angivna key inte ger någon träff. En återställningsnyckel söker efter en nyckel med prefix och returnerar den senast skapade cacheposten. Detta är användbart när pipelinen inte kan hitta en exakt matchning men ändå vill använda en partiell cacheträff.

Om du vill ange flera återställningsnycklar anger du dem på separata rader. Ordningen i vilken återställningsnycklarna provas är uppifrån och ned.

Exempel:

Här är ett exempel på hur du använder återställningsnycklar för att cachea Yarn-paket.

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

I det här exemplet försöker cacheaktiviteten först återställa den angivna nyckeln. Om nyckeln inte finns i cacheminnet försöker den sedan med den första återställningsnyckeln: yarn | $(Agent.OS). Detta söker efter cachenycklar som exakt matchar eller börjar med det här prefixet.

En prefixmatchning kan inträffa om hashen för yarn.lock filen har ändrats. Om cachen till exempel innehåller nyckeln yarn | $(Agent.OS) | old-yarn.lock (där old-yarn.lock har en annan hash än den aktuella yarn.lock) skulle återställningsnyckeln resultera i en partiell cacheträff.

Om den första återställningsnyckeln inte ger någon matchning söker nästa återställningsnyckel (yarn) Efter en cachenyckel som börjar med yarn. För prefixmatchningar returnerar återställningsprocessen den senast skapade cacheposten.

Obs

En pipeline kan innehålla flera cachelagringsuppgifter och det finns ingen lagringsgräns för cachelagring. Jobb och uppgifter i samma pipeline kan komma åt och dela samma cache.

Använd återställningsläge

I vissa scenarier kanske du vill köra steg villkorligt baserat på om cacheminnet har återställts. Du kan till exempel hoppa över ett steg som installerar beroenden om cacheminnet återställdes. Detta kan uppnås med argumentet cacheHitVar .

Om du anger den här indatan till namnet på en miljövariabel anges variabeln till true när det finns en cacheträff, inexact om en återställningsnyckel ger en partiell cacheträff och false om ingen cache hittas. Du kan sedan referera till den här variabeln i ett stegvillkor eller i ett skript.

Här är ett exempel där install-deps.sh steget hoppas över när cacheminnet återställs:

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

Cacheisolering och säkerhet

För att säkerställa isolering mellan cacheminnen från olika pipelines och olika grenar lagras varje cache i en logisk container som kallas ett omfång. Scope fungerar som en säkerhetsgräns som garanterar:

Jobb från en pipeline kan inte komma åt cacheminnen från en annan pipeline.
Jobb som skapar pull-begäranden kan läsa cacheminnen från målgrenen (för samma pipeline), men kan inte skriva (skapa) cacheminnen i målgrenens omfång.

När ett cachesteg påträffas under en körning begärs den av nyckeln identifierade cachen från servern. Servern letar sedan efter en cache med den här nyckeln från de omfång som är synliga för jobbet och returnerar cacheminnet (om tillgängligt). När cachen sparas (i slutet av jobbet) skrivs den till det område som representerar pipelinen och grenen.

CI, manuella och schemalagda processer

Omfattning	Läsa	Skriva
Källgren	Ja	Ja
`main` gren	Ja	Nej
`master` gren	Ja	Nej

Pull-begäranden genomförs

Omfattning	Läsa	Skriva
Källgren	Ja	Nej
Målfilial	Ja	Nej
Mellanliggande gren (till exempel `refs/pull/1/merge`)	Ja	Ja
`main` gren	Ja	Nej
`master` gren	Ja	Nej

Körningar av förgrenade pull-begäranden

Gren	Läsa	Skriva
Målfilial	Ja	Nej
Mellanliggande gren (till exempel `refs/pull/1/merge`)	Ja	Ja
`main` gren	Ja	Nej
`master` gren	Ja	Nej

Tips

Eftersom cacheminnen redan är begränsade till ett projekt, en pipeline och en gren behöver du inte inkludera några projekt-, pipeline- eller grenidentifierare i cachenyckeln.

Exempel

För Ruby-projekt som använder Bundler åsidosätter du BUNDLE_PATH miljövariabeln för att ange sökvägen där Bundler letar efter Gems.

Exempel:

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 är en kompilatorcache för C/C++. Om du vill använda Ccache i pipelinen kontrollerar du att Ccache har installerats och eventuellt läggs till i din PATH (se Ccache-körningslägen). Ange miljövariabeln CCACHE_DIR till en sökväg under $(Pipeline.Workspace) och cachelagra denna katalog.

Exempel:

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

Mer information finns i Konfigurationsinställningar för Ccache.

Cachelagring av Docker-avbildningar kan avsevärt minska den tid det tar att köra pipelinen.

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'        ## A unique identifier for the cache
      path: $(Pipeline.Workspace)/docker           ## Path of the folder or file that you want to cache
      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'))

Exempel med docker buildx:

steps:
  - task: Cache@2
    displayName: Cache Docker
    inputs:
      key: 'docker | "$(Agent.OS)" | mydockerimage | ./Dockerfile'
      path: $(Pipeline.Workspace)/docker_image_cache
      restoreKeys: |
        docker | "$(Agent.OS)" | mydockerimage

  - script: |
      docker buildx create --name builder --driver docker-container --use
      docker buildx build \
        --cache-from=type=local,src=$(Pipeline.Workspace)/docker_image_cache \
        --cache-to=type=local,dest=$(Pipeline.Workspace)/docker_image_cache,mode=max \
        --file ./Dockerfile \
        --output=type=docker,name=mydockerimage \
        .
    displayName: docker buildx
    env:
      DOCKER_BUILDKIT: 1

För Golang-projekt kan du ange vilka paket som ska laddas ned i filen go.mod. Om din GOCACHE variabel inte redan har angetts anger du den till den där du vill att cachen ska laddas ned.

Exempel:

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

Att använda Gradles inbyggda cachestöd kan ha en betydande inverkan på byggtiden. Om du vill aktivera byggcachen anger du miljövariabeln GRADLE_USER_HOME till en sökväg under $(Pipeline.Workspace) och kör antingen bygget med --build-cache eller lägger till org.gradle.caching=true i gradle.properties-filen.

Exempel:

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: |                                      # The fallback keys if the primary key fails (Optional)
      gradle | "$(Agent.OS)"
      gradle
    path: $(GRADLE_USER_HOME)
  displayName: Configure gradle caching

- task: Gradle@4                            # Build using a Gradle wrapper script
  inputs:
    gradleWrapperFile: 'gradlew'            # Alias: wrapperScript. Gradle wrapper.
    tasks: 'build'                          # Default: build. Gradle tasks.
    options: '--build-cache'                # String. Gradle options.
  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

Obs

Cacher är oföränderliga. När en cache med en viss nyckel har skapats för ett specifikt omfång (till exempel en gren) kan den inte uppdateras. Det innebär att om du använder ett fast nyckelvärde kommer alla efterföljande versioner för samma gren inte att kunna uppdatera cacheminnet , även om cacheinnehållet har ändrats. Om du använder en fast nyckel måste du ange restoreKeys indata som reservalternativ.

Maven använder en lokal lagringsplats för att lagra nedladdade beroenden och skapade artefakter. Om du vill aktivera cachelagring anger du maven.repo.local alternativet till en sökväg under $(Pipeline.Workspace) och cachelagra den här mappen.

Exempel:

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

Om du använder en Maven-aktivitetska du även skicka variabeln MAVEN_OPTS eftersom den skrivs över annars:

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

Om du använder PackageReferences för att hantera NuGet-beroenden direkt i projektfilen och har en packages.lock.json fil kan du aktivera cachelagring genom att ange NUGET_PACKAGES miljövariabeln till en sökväg under $(UserProfile) och cachelagra den här katalogen. Mer information om hur du låser beroenden finns i Paketreferens i projektfiler.

Om du vill använda flera packages.lock.jsonkan du fortfarande använda följande exempel utan att göra några ändringar. Innehållet i alla packages.lock.json filer hashas och om en av filerna ändras genereras en ny cachenyckel.

Exempel:

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

Den här metoden är också giltig för .NET Core-projekt om projektet använder packages.lock.json för att låsa paketversioner. Du kan aktivera detta genom att ställa in RestorePackagesWithLockFile till True i din Csproj--fil eller med hjälp av följande kommando: dotnet restore --use-lock-file.

Det finns olika sätt att aktivera cachelagring i ett Node.js projekt, men den rekommenderade metoden är att cachelagra npm:s delade cachekatalog. Den här katalogen hanteras av npm och innehåller en cachelagrad version av alla nedladdade moduler. Under installationen kontrollerar npm den här katalogen först (som standard), vilket kan minska eller eliminera nätverksanrop till det offentliga npm-registret eller ett privat register.

Eftersom standardsökvägen till npm:s delade cachekatalog varierar mellan plattformar rekommenderar vi att du åsidosätter npm_config_cache miljövariabeln och anger den till en sökväg under $(Pipeline.Workspace). Detta säkerställer också att cachen är tillgänglig från både container- och icke-behållarjobb.

Exempel:

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

Om projektet inte har någon package-lock.json-fil, refererar du till den package.json-filen i cache-nyckelns indata istället.

Tips

Eftersom npm ci tar bort node_modules mappen för att säkerställa en konsekvent och repeterbar uppsättning moduler bör du undvika cachelagring node_modules när du använder npm ci.

Precis som npm erbjuder Yarn flera sätt att cachelagrat installerade paket. Den rekommenderade metoden är att cachelagrat Yarns delade cachemapp. Den här katalogen hanteras av Yarn och lagrar cachelagrade versioner av alla nedladdade paket. Under installationen kontrollerar Yarn den här katalogen först (som standard), vilket kan minska eller till och med eliminera nätverksanrop till offentliga eller privata register.

Exempel:

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

Konfigurera cachelagring för din pipeline med Anaconda-miljöer:

Exempel

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

För PHP-projekt som använder Composer åsidosätter du miljövariabeln COMPOSER_CACHE_DIR som används av Composer.

Exempel:

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

Kända problem och feedback

Om du har problem med att konfigurera cachelagring i pipelinen kontrollerar du listan över öppna problem på lagringsplatsen microsoft/azure-pipelines-tasks . Om du inte ser ditt problem i listan skapa en ny och ange nödvändig information om ditt scenario.

Frågor och svar

F: Kan jag rensa en cache?

S: Det går inte att rensa en cache. Du kan dock undvika träffar på befintliga cacheminnen genom att lägga till en strängliteral (till exempel version2) i cachenyckeln. Ändra till exempel följande cachenyckel från detta:

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

Så här gör du:

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

F: När upphör en cache att gälla?

Cacher går ut efter sju dagar utan aktivitet.

F: När laddas cachen upp?

S: En cache skapas från din angivna path och laddas upp efter det sista steget i jobbet. Mer information finns i exempel.

F: Finns det en gräns för storleken på en cache?

S: Det finns ingen framtvingad gräns för storleken på enskilda cacheminnen eller den totala cachestorleken i en organisation.

Feedback

Var den här sidan till hjälp?

Dela via

Pipeline-cache

När du ska använda pipelineartefakter kontra pipelinecachelagring

Krav för lokalt installerad agent

Cacheaktivitet: Så här fungerar den

Konfigurera cachningsuppgiften

Använd återställningsnycklar

Använd återställningsläge

Cacheisolering och säkerhet

CI, manuella och schemalagda processer

Pull-begäranden genomförs

Körningar av förgrenade pull-begäranden

Exempel

Kända problem och feedback

Frågor och svar

F: Kan jag rensa en cache?

F: När upphör en cache att gälla?

F: När laddas cachen upp?

F: Finns det en gräns för storleken på en cache?

Relaterat innehåll

Feedback

Ytterligare resurser