Sdílet prostřednictvím


Ukládání do mezipaměti kanálu

Azure DevOps Services

Ukládání do mezipaměti v rámci kanálu může pomoci zkrátit dobu sestavení tím, že umožňuje opětovné použití výstupů nebo stažených závislostí z jednoho spuštění v pozdějších spuštěních, čímž dojde ke snížení nebo zamezení nákladů na opětovné vytvoření nebo stažení stejných souborů. Ukládání do mezipaměti je užitečné zejména ve scénářích, kdy se při každém spuštění stahují stejné závislosti. To je často časově náročný proces zahrnující stovky nebo tisíce síťových volání.

Ukládání do mezipaměti může být efektivní při vylepšení doby sestavení za předpokladu, že doba obnovení a uložení mezipaměti je kratší než doba, kdy se výstup znovu vytvoří úplně od začátku. Z tohoto důvodu nemusí být ukládání do mezipaměti efektivní ve všech scénářích a může mít ve skutečnosti negativní dopad na čas sestavení.

Poznámka

Ukládání do mezipaměti kanálu není podporováno v klasických vydávacích kanálech.

Kdy použít artefakty nebo ukládání do mezipaměti

Ukládání sestavy do mezipaměti a artefakty sestavy provádějí podobné funkce, ale jsou navrženy pro různé scénáře a neměly by se používat zaměnitelně.

  • Použijte artefakty z potrubí, když potřebujete získat konkrétní soubory vytvořené v jedné úloze a sdílet je s jinými úlohami (a tyto další úlohy bez nich pravděpodobně nebudou fungovat správně).

  • Použijte ukládání do mezipaměti kanálu, když chcete zlepšit dobu sestavení tím, že znovu použijete soubory z předchozích spuštění (a jejich absence nebude mít vliv na schopnost úlohy běžet).

Poznámka

Ukládání kanálů do mezipaměti a artefakty kanálu jsou bezplatné pro všechny úrovně (bezplatné a placené). Další podrobnosti najdete v tématu Využití úložiště Artifacts.

Úloha mezipaměti: jak funguje

Ukládání do mezipaměti je přidáno do kanálu pomocí úlohy mezipaměti. Tento úkol funguje stejně jako jakýkoli jiný úkol a je přidán do steps části úlohy.

Když během spuštění dojde ke kroku mezipaměti, úloha obnoví mezipaměť na základě zadaných vstupů. Pokud se nenajde žádná mezipaměť, krok se dokončí a spustí se další krok v úloze.

Po spuštění všech kroků v úloze a za předpokladu, že úspěšné stavu úlohy, se automaticky přidá speciální krok Post-job: Cache krok se automaticky přidá a aktivuje pro každý "mezipaměť obnovení" kroku, který se nepřeskočil. Tento krok zodpovídá za ukládání mezipaměti.

Poznámka

Mezipaměti jsou neměnné, což znamená, že po vytvoření mezipaměti je jeho obsah neměnný.

Konfigurace úlohy mezipaměti

Úloha mezipaměti má dva povinné argumenty: klíč a cestu.

  • cesta: cesta ke složce do mezipaměti. Může to být absolutní nebo relativní cesta. Relativní cesty jsou vyhodnocovány ve vztahu k $(System.DefaultWorkingDirectory).

Poznámka

Pomocí předdefinovaných proměnných můžete uložit cestu ke složce, do které chcete ukládat do mezipaměti, ale zástupné kóty se nepodporují.

  • klíč: měla by být nastavena na identifikátor mezipaměti, kterou chcete obnovit nebo uložit. Klíče se skládají z kombinace řetězcových hodnot, cest k souborům nebo vzorů souborů, kde je každý segment oddělený znakem |.
  • řetězců:
    Pevná hodnota (například název mezipaměti nebo názvu nástroje) nebo převzatá z proměnné prostředí (například aktuální operační systém nebo název aktuální úlohy)

  • cesty k souborům:
    Cesta ke konkrétnímu souboru, jehož obsah bude hashován. Tento soubor musí existovat v době, kdy je úloha spuštěna. Mějte na paměti, že jakýkoli segment klíče, který "vypadá jako cesta k souboru", bude považován za cestu k souboru. To zejména zahrnuje segmenty obsahující .. To může vést k selhání úlohy v případě, že tento soubor neexistuje.

    Spropitné

    Pokud se chcete vyhnout tomu, aby se s řetězcovým segmentem podobným cestě zacházelo jako s cestou k souboru, zabalte ho dvojitými uvozovkami, například: "my.key" | $(Agent.OS) | key.file

  • vzory souborů :
    Čárkami oddělený seznam zástupných znaků ve stylu globu, který musí odpovídat alespoň jednomu souboru. Například:

    • **/yarn.lock: všechny soubory yarn.lock v adresáři zdrojů
    • */asset.json, !bin/**: všechny soubory asset.json umístěné v adresáři pod adresářem zdrojů s výjimkou adresáře bin

Obsah libovolného souboru identifikovaného cestou k souboru nebo vzorem souboru je hashován, aby se vytvořil klíč dynamické mezipaměti. To je užitečné, když má váš projekt soubory, které jednoznačně identifikují, co se ukládá do mezipaměti. Například soubory jako package-lock.json, yarn.lock, Gemfile.locknebo Pipfile.lock se běžně odkazují v klíči mezipaměti, protože všechny představují jedinečnou sadu závislostí.

Relativní cesty k souborům nebo vzory souborů jsou vyřešeny proti $(System.DefaultWorkingDirectory).

příklad:

Tady je příklad ukazující, jak ukládat závislosti nainstalované pomocí Yarn do mezipaměti:

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

V tomto příkladu klíč mezipaměti obsahuje tři části: statický řetězec ("yarn"), operační systém, na kterém je úloha spuštěná, protože tato mezipaměť je jedinečná pro operační systém a hodnota hash souboru yarn.lock, který jednoznačně identifikuje sadu závislostí v mezipaměti.

Při prvním spuštění po přidání úlohy krok mezipaměti nahlásí "neúspěšný pokus o nalezení mezipaměti", protože mezipaměť identifikovaná tímto klíčem neexistuje. Po posledním kroku se vytvoří mezipaměť ze souborů v $(Pipeline.Workspace)/s/.yarn a nahraje se. Při příštím spuštění krok mezipaměti nahlásí "zásah do mezipaměti" a obsah mezipaměti se stáhne a obnoví.

Při použití checkout: selfje úložiště rezervováno pro $(Pipeline.Workspace)/sa vaše složka .yarn se obvykle nachází v samotném úložišti.

Poznámka

Pipeline.Workspace je místní cesta agenta, na kterém běží váš kanál, ve kterém jsou vytvořeny všechny adresáře. Tato proměnná má stejnou hodnotu jako Agent.BuildDirectory.

Nezapomeňte aktualizovat proměnnou YARN_CACHE_FOLDER, pokud používáte něco jiného než checkout: self, protože by mělo odkazovat na úložiště, kde se nachází .yarn.

Obnovení klíčů

restoreKeys lze použít, pokud se chcete dotazovat na více přesných klíčů nebo předpon klíčů. Toto se používá k návratu k jinému klíči v případě, že key nepřináší úspěšný pokus. Obnovovací klíč vyhledá klíč podle předpony a v důsledku toho získá nejnovější vytvořenou položku mezipaměti. To je užitečné, pokud potrubí nemůže najít přesnou shodu, ale místo toho chce použít částečný zásah do mezipaměti. Pokud chcete vložit více klíčů obnovení, oddělte je pomocí nového řádku a označte klíč obnovení (další podrobnosti najdete v příkladu). Pořadí, ve kterém se klíče obnovení budou zkoušet, budou odshora dolů.

Požadovaný software na self-hostovaném agentu

Archivní software / platforma Windows Linux Mac
GNU Tar Povinný Požadovaný Ne
BSD Tar Ne Ne Povinný
7-Zip Doporučený Ne Ne

Výše uvedené spustitelné soubory musí být ve složce uvedené v proměnné prostředí PATH. Mějte na paměti, že hostovaní agenti se dodávají s již nainstalovaným softwarem; to platí pouze pro agenty hostované místně.

Příklad :

Tady je příklad použití obnovovaných klíčů podle 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

V tomto příkladu se úloha mezipaměti pokusí zjistit, jestli klíč existuje v mezipaměti. Pokud klíč v mezipaměti neexistuje, pokusí se použít první obnovovací klíč yarn | $(Agent.OS). Tím se pokusíte vyhledat všechny klíče, které přesně odpovídají danému klíči, nebo má tento klíč jako předponu. K zásahu předpony může dojít, pokud existuje jiný segment hash yarn.lock. Pokud například následující klíč yarn | $(Agent.OS) | old-yarn.lock byl v mezipaměti, kde old-yarn.lock vygeneroval jinou hash než yarn.lock, obnovovací klíč by přinesl částečný zásah. Pokud u prvního klíče obnovení dojde k chybě, použije se další klíč obnovení yarn, který se pokusí najít libovolný klíč, který začíná yarn. Výsledkem pro zásahy předpony je naposledy vytvořený klíč mezipaměti.

Poznámka

Potrubí může mít jednu nebo více úloh ukládání do mezipaměti. Kapacita úložiště pro ukládání do mezipaměti není nijak omezena a úlohy a úkoly ze stejného kanálu mohou přistupovat ke stejné mezipaměti a sdílet ji.

Izolace a zabezpečení mezipaměti

Aby se zajistila izolace mezi mezipamětí z různých kanálů a různých větví, každá mezipaměť patří do logického kontejneru označovaného jako obor. Rozsahy poskytují bezpečnostní hranici, která zajišťuje:

  1. Úloha z jednoho potrubí nemůže přistupovat k mezipamětím z jiného potrubí a
  2. Úloha sestavující žádost o přijetí změn (PR) má přístup pro čtení k mezipamětem pro cílovou větev PR (pro stejnou pipeline), ale nemůže zapisovat (vytvářet) mezipaměti v rámci cílové větve.

Když během spuštění dojde k kroku mezipaměti, vyžádá se ze serveru mezipaměť identifikovaná klíčem. Server pak vyhledá mezipaměť s tímto klíčem z oborů viditelných pro úlohu a vrátí mezipaměť (pokud je k dispozici). Při ukládání mezipaměti (na konci úlohy) se mezipaměť zapíše do rozsahu, který představuje potrubí a větev. Další podrobnosti najdete níže.

CI, ruční a naplánovaná spuštění

Rozsah Číst Psát
Zdrojová větev Ano Ano
větev main Ano Ne
větev master Ano Ne

Spuštění žádostí o přijetí změn

Rozsah Číst Psát
Zdrojová větev Ano Ne
Cílová větev Ano Ne
Zprostředkovací větev (například refs/pull/1/merge) Ano Ano
větev main Ano Ne
větev master Ano Ne

Spuštění forku pull requestu

Větev Číst Psát
Cílová větev Ano Ne
Mezilehlá větev (například refs/pull/1/merge) Ano Ano
větev main Ano Ne
větev master Ano Ne

Spropitné

Vzhledem k tomu, že mezipaměti jsou již vymezeny na projekt, kanál a větev, není nutné do klíče mezipaměti zahrnout žádné identifikátory projektu, kanálu nebo větve.

Klimatizace při obnovení mezipaměti

V některých scénářích by úspěšné obnovení mezipaměti mělo způsobit spuštění jiné sady kroků. Například krok, který nainstaluje závislosti, se dá přeskočit, pokud se mezipaměť obnovila. Pomocí vstupu úkolu cacheHitVar je to možné. Nastavení tohoto vstupu na název systémové proměnné způsobí, že se proměnná nastaví na true při zasažení mezipaměti, na inexact při zasažení obnovovací klíčové mezipaměti, jinak se nastaví na false. Na tuto proměnnou pak můžete odkazovat v podmínce kroku nebo ve skriptu.

V následujícím příkladu se při obnovení mezipaměti přeskočí krok install-deps.sh.

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

U projektů Ruby, které využívají Bundler, přepište proměnnou prostředí BUNDLE_PATH, kterou Bundler používá k nastavení cesty , ve které Bundler hledá Gems.

příklad :

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 je mezipaměť kompilátoru pro C/C++. Pokud chcete použít Ccache ve vašem pipeline, ujistěte se, že je nainstalovaný Ccache a volitelně přidán do PATH (viz režimy spuštění Ccache). Nastavte proměnnou prostředí CCACHE_DIR na cestu pod $(Pipeline.Workspace) a uložit tento adresář do mezipaměti.

příklad:

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

Další podrobnosti najdete v tématu konfigurační nastavení Ccache.

Obrazy Dockeru

Ukládání obrazů Dockeru do mezipaměti výrazně zkracuje čas potřebný ke spuštění kanálu.

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'))
  • klíč: (povinné) – jedinečný identifikátor mezipaměti.
  • cesta: (povinné) – cesta ke složce nebo souboru, který chcete uložit do mezipaměti.

Jazyk Go

U projektů jazyka Go můžete zadat balíčky, které se mají stáhnout v souboru go.mod. Pokud vaše GOCACHE proměnná ještě není nastavená, nastavte ji na místo, kam chcete mezipaměť stáhnout.

Příklad:

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

Použití integrované podpory ukládání do mezipaměti gradle může mít významný vliv na čas sestavení. Pokud chcete povolit mezipaměť sestavení, nastavte proměnnou prostředí GRADLE_USER_HOME na cestu pod $(Pipeline.Workspace) a spusťte sestavení pomocí --build-cache nebo přidejte org.gradle.caching=true do souboru gradle.properties.

příklad :

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: Náhradní klíče, pokud primární klíč selže (volitelné)

Poznámka

Mezipaměti jsou neměnné, jakmile se vytvoří mezipaměť s konkrétním klíčem pro určitý obor (větev), mezipaměť nelze aktualizovat. To znamená, že pokud je klíč pevnou hodnotou, nebudou moci všechna následná sestavení pro stejnou větev aktualizovat mezipaměť ani v případě, že se změnil obsah mezipaměti. Pokud chcete použít pevnou hodnotu klíče, musíte jako záložní možnost použít argument restoreKeys.

Odborník

Maven má místní úložiště, ve kterém ukládá stažené a sestavené artefakty. Pokud chcete povolit, nastavte možnost maven.repo.local na cestu pod $(Pipeline.Workspace) a tuto složku uložit do mezipaměti.

Příklad :

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

Pokud používáte úlohu Maven, nezapomeňte také předat proměnnou MAVEN_OPTS, jinak se přepíše:

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

.NET/NuGet

Pokud používáte PackageReferences ke správě závislostí NuGet přímo v souboru projektu a máte packages.lock.json soubor, můžete ukládání do mezipaměti povolit nastavením proměnné prostředí NUGET_PACKAGES na cestu pod $(UserProfile) a uložením tohoto adresáře do mezipaměti. Další podrobnosti o tom, jak zamknout závislosti, najdete v referenčních informacích o balíčku v souborech projektu. Pokud chcete použít více packages.lock.json, můžete dál použít následující příklad, aniž byste museli provádět změny. Obsah všech packages.lock.json souborů bude hashován a pokud se některý ze souborů změní, vygeneruje se nový klíč mezipaměti.

Příklad:

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

Tento přístup platí také pro projekty .NET Core, pokud váš projekt používá packages.lock.json k uzamčení verzí balíčků. Můžete to povolit nastavením RestorePackagesWithLockFile na True v souboru Csproj nebo pomocí následujícího příkazu: dotnet restore --use-lock-file.

Node.js/npm

Ukládání do mezipaměti v projektu Node.js lze povolit různými způsoby, ale doporučeným způsobem je ukládat do mezipaměti adresář sdílené mezipaměti npm. Tento adresář spravuje npm a obsahuje verzi všech stažených modulů v mezipaměti. Během instalace npm nejprve zkontroluje tento adresář (ve výchozím nastavení) pro moduly, které můžou omezit nebo eliminovat síťová volání veřejného registru npm nebo do privátního registru.

Vzhledem k tomu, že výchozí cesta k adresáři sdílené mezipaměti npm je , není stejná pro všechny platformy, doporučuje se upravit proměnnou prostředí npm_config_cache na cestu, která spadá pod $(Pipeline.Workspace). Tím také zajistíte, že mezipaměť bude přístupná z kontejnerových a nekontejnerových úloh.

Příklad :

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

Pokud váš projekt nemá soubor package-lock.json, odkazujte místo toho na soubor package.json ve vstupu klíče mezipaměti.

Spropitné

Protože npm ci odstraní složku node_modules, aby se zajistila konzistentní, opakovatelná sada modulů, měli byste se vyhnout ukládání do mezipaměti node_modules při volání npm ci.

Node.js/Příze

Stejně jako u npm existují různé způsoby ukládání balíčků nainstalovaných do mezipaměti s Yarn. Doporučeným způsobem je ukládat sdílené složky mezipaměti Yarn. Tento adresář spravuje Yarn a obsahuje verzi uložené v mezipaměti všech stažených balíčků. Během instalace Yarn nejprve zkontroluje tento adresář (ve výchozím nastavení) pro moduly, které můžou omezit nebo eliminovat síťová volání veřejných nebo privátních registrů.

Příklad:

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

Nastavte ukládání do mezipaměti pomocí prostředí Anaconda:

Příklad

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

U projektů PHP používajících Composer přepište proměnnou prostředí COMPOSER_CACHE_DIR, kterou používá Composer.

Příklad :

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

Známé problémy a zpětná vazba

Pokud máte problémy s nastavením mezipaměti pro pipeline, zkontrolujte seznam otevřených problémů v úložišti microsoft/azure-pipelines-tasks. Pokud váš problém není uveden, vytvořte nový a poskytněte potřebné informace o vašem scénáři.

Q&A

Otázka: Můžu vymazat mezipaměť?

A: Vymazání mezipaměti se v současné době nepodporuje. K vašemu stávajícímu klíči mezipaměti můžete přidat řetězcový literál (například version2), abyste klíč změnili tak, že se tím vyhnete zásahům do stávajících mezipamětí. Například změňte následující klíč mezipaměti z tohoto:

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

Na toto:

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

Otázka: Kdy vyprší platnost mezipaměti?

A: Platnost mezipaměti vyprší po sedmi dnech bez aktivity.

Otázka: Kdy se mezipaměť nahraje?

A: Po posledním kroku vašeho kanálu bude vytvořena mezipaměť z vaší mezipaměti path a nahraje se. Další podrobnosti najdete v příkladu.

Otázka: Existuje omezení velikosti mezipaměti?

A: Neexistuje žádné vynucené omezení velikosti jednotlivých mezipamětí ani celkové velikosti všech mezipamětí v organizaci.