Csővezeték gyorsítótárazása

Azure DevOps Services

A folyamatok gyorsítótárazása segíthet csökkenteni a buildelési időt a korábbi futtatásokból letöltött függőségek újrafelhasználásával, így elkerülhető, hogy ugyanazokat a fájlokat újra létre vagy újra letöltsék. Ez különösen hasznos olyan esetekben, amikor ugyanazok a függőségek lesznek ismételten letöltve az egyes futtatások elején. Ez gyakran több száz vagy több ezer hálózati hívással járó időigényes folyamat.

A gyorsítótárazás akkor a leghatékonyabb, ha a gyorsítótár visszaállításához és mentéséhez szükséges idő rövidebb, mint a fájlok újragenerálásához szükséges idő. Bizonyos esetekben azonban előfordulhat, hogy a gyorsítótárazás nem nyújt teljesítménybeli előnyöket, sőt negatívan befolyásolhatja a buildelési időt. Fontos kiértékelni az adott forgatókönyvet annak megállapításához, hogy a gyorsítótárazás a megfelelő megközelítés-e.

Jegyzet

A folyamatok gyorsítótárazása nem támogatott a klasszikus kiadási folyamatok esetében.

Mikor érdemes folyamat-összetevőket használni a folyamat gyorsítótárazásához képest?

A folyamat-gyorsítótárazás és a folyamat-összetevők hasonló funkciókat hajtanak végre, de különböző forgatókönyvekhez készültek, és nem használhatók felcserélhetően.

• Folyamat-összetevők használata: amikor egy feladat által előállított fájlokat kell használnia, és meg kell osztania őket más feladatokkal (és ezek a többi feladat valószínűleg meghiúsulnának nélkülük).

• Folyamat-gyorsítótárazás használata: ha a korábbi futtatások fájljainak újrafelhasználásával szeretné javítani a buildelési időt (és ha nem rendelkezik ezekkel a fájlokkal, az nem befolyásolja a feladat futtatási képességét).

Jegyzet

A folyamat-gyorsítótárazás és a folyamat-összetevők díjmentesen érhetők el minden szinten (ingyenes és fizetős). További részletekért lásd az Artifacts tárolási fogyasztását .

A saját üzemeltetésű ügynökre vonatkozó követelmények

A következő végrehajtható fájloknak a környezeti változóban felsorolt PATH mappában kell lenniük. Vegye figyelembe, hogy ezek a követelmények csak a saját üzemeltetésű ügynökökre vonatkoznak, mivel az üzemeltetett ügynökök előre telepítve vannak a szükséges szoftverrel.

Archív szoftver / platform	Windows	Linux	Mac
GNU Tar	Szükséges	Szükséges	Nem
BSD kátrány	Nem	Nem	Szükséges
7 cipzáras	Ajánlott	Nem	Nem

Gyorsítótár-feladat: Hogyan működik

A gyorsítótárazás úgy kerül a folyamatba, hogy hozzáadja a Gyorsítótár feladatotsteps egy feladat szakaszához.

A folyamat végrehajtása során, ha gyorsítótár-lépéssel találkozik, a feladat a megadott bemenetek alapján próbálja meg visszaállítani a gyorsítótárat. Ha nem található gyorsítótár, a lépés befejeződik, és a feladat következő lépése végrehajtásra kerül.

A feladat összes lépésének sikeres futtatása után a rendszer automatikusan hozzáad egy speciális "Feladat utáni: Gyorsítótár" lépést, és aktiválódik minden olyan "gyorsítótár visszaállítása" lépéshez, amelyet nem hagytak ki. Ez a lépés felelős a gyorsítótármentéséért.

Jegyzet

A gyorsítótárak nem módosíthatók. A gyorsítótár létrehozása után a tartalma nem módosítható.

A Gyorsítótár-feladat konfigurálása

A Cache feladatnak két kötelező argumentuma van: elérési út és kulcs:

1. elérési út: A gyorsítótárazni kívánt mappa elérési útja. Ez lehet abszolút vagy relatív elérési út. A relatív elérési utak a $(System.DefaultWorkingDirectory)-hoz képest vannak megoldva.

   Borravaló

   Előre definiált változók segítségével tárolhatja a gyorsítótárazni kívánt mappa elérési útját. A helyettesítő karakterek azonban nem támogatottak.

2. key: Ez határozza meg a visszaállítani vagy menteni kívánt gyorsítótár azonosítóját. A kulcs sztringértékek, fájlelérési utak vagy fájlminták kombinációjából áll, és minden szegmenst egy | karakter választ el egymástól.

   • Húrok:
     Rögzített érték (például a gyorsítótár neve vagy egy eszköz neve), vagy egy környezeti változóból (például az aktuális operációs rendszer vagy feladat neve) származik.

   • fájl elérési útjai:
     Egy adott fájl elérési útja, amelynek tartalma kivonatolva lesz. A fájlnak léteznie kell a feladat futtatásakor. A rendszer minden olyan szegmenst, amely hasonlít a fájl elérési útjára, ezért legyen óvatos, különösen a , mivel .ez a "fájl nem létezik" hibákhoz vezethet.

     Borravaló

     Ha szeretné elkerülni, hogy egy elérési úthoz hasonló sztringszegmens fájlútvonalként legyen kezelve, csomagolja be dupla idézőjelekkel, például: "my.key" | $(Agent.OS) | key.file

   • fájlminták:
     Gömb stílusú helyettesítő karakteres minták vesszővel tagolt listája, amelyeknek legalább egy fájlnak meg kell egyezniük. Példák:

     • **/yarn.lock: az összes yarn.lock fájl a források könyvtárban.
     • */asset.json, !bin/**: a forráskönyvtár alatti könyvtárban található összes asset.json fájl, kivéve azokat, amelyek a bin könyvtárban vannak.

A fájl elérési útja vagy fájlmintája által azonosított fájlok tartalma kivonatolva dinamikus gyorsítótár-kulcsot hoz létre. Ez akkor hasznos, ha a projekt olyan fájlokkal rendelkezik, amelyek egyedileg azonosítják a gyorsítótárazott fájlokat. Például az olyan fájlok, mint a package-lock.json, yarn.lock, Gemfile.lockvagy Pipfile.lock gyakran hivatkoznak egy gyorsítótárkulcsban, mivel ezek egyedi függőségeket képviselnek. A relatív fájlelérési utak vagy minták feloldása a $(System.DefaultWorkingDirectory).

• példa:

Az alábbi példa bemutatja, hogyan gyorsítótárazhatja a fonalcsomagokat:

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

Ebben a példában a gyorsítótárkulcs három részből áll: egy statikus sztringből ("fonalból"), az operációs rendszerből, amelyen a feladat fut (mivel a gyorsítótár operációs rendszerenként egyedi) és a yarn.lock fájl kivonatából (amely egyedileg azonosítja a függőségeket).

A feladat hozzáadása utáni első futtatáskor a gyorsítótár-lépés "gyorsítótár-hiányt" jelez, mert a kulcs által azonosított gyorsítótár nem létezik. Az utolsó lépés után a rendszer létrehoz egy gyorsítótárat a $(Pipeline.Workspace)/s/.yarn fájljaiból, és feltölti. A következő futtatáskor a gyorsítótár lépése "gyorsítótár-találatot" jelent, és a gyorsítótár tartalma le lesz töltve és visszaállítva.

A használatakor checkout: selfa tárházat a rendszer kiveszi a $(Pipeline.Workspace)/s, és a .yarn mappa valószínűleg magában az adattárban fog elhelyezkedni.

Jegyzet

Pipeline.Workspace a folyamatot futtató ügynök helyi elérési útja, ahol az összes címtár létrejön. Ez a változó ugyanazzal az értékkel rendelkezik, mint Agent.BuildDirectory. Ha nem használja checkout: self, győződjön meg arról, hogy frissíti a változót YARN_CACHE_FOLDER , hogy az adattárban lévő helyre .yarn mutasson.

Visszaállítási kulcsok használata

restoreKeys Lehetővé teszi több pontos kulcs vagy kulcselőtag lekérdezését. Tartalékként használatos, ha a megadott key nem ad találatot. A visszaállítási kulcs előtag alapján keres egy kulcsot, és a legutóbb létrehozott gyorsítótár-bejegyzést adja vissza. Ez akkor hasznos, ha a folyamat nem talál pontos egyezést, de továbbra is részleges gyorsítótár-lekérést szeretne használni.

Több visszaállítási kulcs megadásához sorolja fel őket külön sorokban. A visszaállítási kulcsok kipróbálásának sorrendje fentről lefelé halad.

• példa:

Íme egy példa arra, hogyan használhat visszaállítási kulcsokat a fonalcsomagok gyorsítótárazásához:

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

Ebben a példában a gyorsítótár-feladat először megpróbálja visszaállítani a megadott kulcsot. Ha a kulcs nem létezik a gyorsítótárban, akkor megpróbálja az első visszaállítási kulcsot: yarn | $(Agent.OS). Ez megkeresi azokat a gyorsítótár-kulcsokat, amelyek pontosan megfelelnek ennek az előtagnak, vagy azzal kezdődnek.

Előtagegyezés akkor fordulhat elő, ha a yarn.lock fájl kivonata megváltozott. Ha például a gyorsítótár tartalmazza a kulcsot yarn | $(Agent.OS) | old-yarn.lock (ahol old-yarn.lock az aktuálistól yarn.lockeltérő kivonattal rendelkezik), ez a visszaállítási kulcs részleges gyorsítótár-találatot eredményez.

Ha az első visszaállítási kulcs nem ad egyezést, a következő visszaállítási kulcs (yarn) Ez minden olyan gyorsítótárkulcsot keres, amely a következővel yarnkezdődik: . Előtagegyezések esetén a visszaállítási folyamat a legutóbb létrehozott gyorsítótár-bejegyzést adja vissza.

Jegyzet

A folyamatok több gyorsítótárazási feladatot is tartalmazhatnak, és a gyorsítótárazáshoz nincs tárolási korlát. Az ugyanazon a folyamaton belüli feladatok és feladatok ugyanazt a gyorsítótárat érhetik el és oszthatják meg.

Visszaállítási feltétel használata

Bizonyos esetekben előfordulhat, hogy feltételesen szeretné végrehajtani a lépéseket attól függően, hogy a gyorsítótár visszaállítása sikeresen megtörtént-e. Kihagyhat például egy olyan lépést, amely függőségeket telepít, ha a gyorsítótár vissza lett állítva. Ez az cacheHitVar érveléssel érhető el.

Ha ezt a bemenetet egy környezeti változó nevére állítja, a változó gyorsítótár-találat esetén lesz beállítva true , inexact ha egy visszaállítási kulcs részleges gyorsítótár-találatot eredményez, és false ha nem található gyorsítótár. Ezután hivatkozhat erre a változóra egy lépésfeltételben vagy egy szkriptben.

Íme egy példa, ahol a rendszer kihagyja a lépést install-deps.sh a gyorsítótár visszaállításakor:

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

Gyorsítótár elkülönítése és biztonsága

A különböző folyamatokból és különböző ágakból származó gyorsítótárak elkülönítésének biztosítása érdekében minden gyorsítótárat egy hatókörnek nevezett logikai tárolóban tárolunk a rendszer. A hatókörök biztonsági határként működnek, amely garantálja a következőket:

• Az egyik folyamatból származó feladatok nem férhetnek hozzá egy másik folyamat gyorsítótáraihoz.

• A lekéréses kérelmeket létrehozó feladatok gyorsítótárakat olvashatnak a célágból (ugyanahhoz a folyamathoz), de nem írhatnak (hozhatnak létre) gyorsítótárakat a célág hatókörében.

Amikor egy futtatás során gyorsítótár-lépés történik, a rendszer a kulcs által azonosított gyorsítótárat kéri a kiszolgálótól. A kiszolgáló ezután megkeresi a feladat számára látható hatókörökből ezt a kulcsot tartalmazó gyorsítótárat, és visszaadja a gyorsítótárat (ha van ilyen). A gyorsítótár mentésekor (a feladat végén) a rendszer a gyorsítótárat a munkafolyamat és ág által képviselt hatókörbe írja.

CI, manuális és ütemezett futtatások

Hatókör	Olvas	Ír
Forráság	Igen	Igen
main ág	Igen	Nem
master ág	Igen	Nem

Pull kérések futtatása

Hatókör	Olvas	Ír
Forráság	Igen	Nem
Célelőfiók	Igen	Nem
Köztes ág (például refs/pull/1/merge)	Igen	Igen
main ág	Igen	Nem
master ág	Igen	Nem

Pull request fork futtatások

Ág	Olvas	Ír
Célelőfiók	Igen	Nem
Köztes ág (például refs/pull/1/merge)	Igen	Igen
main ág	Igen	Nem
master ág	Igen	Nem

Borravaló

Mivel a gyorsítótárak már hatókörrel vannak elosztva egy projektre, folyamatra és ágra, nem kell projekt-, folyamat- vagy ágazonosítókat tartalmaznia a gyorsítótárkulcsban.

Példák

Kötegelő

A Bundlert használó Ruby-projektek esetében bírálja felül a környezeti változót BUNDLE_PATH , hogy beállítsa azt az elérési utat , ahol a Bundler drágaköveket keres.

példa:

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

Ccache a C/C++ fordító gyorsítótára. Ha Ccache-t használ a folyamatában, győződjön meg arról, hogy a Ccache telepítve van, és lehetőség szerint adja hozzá a PATH-hez (lásd Ccache-futtatási módokat). Állítsa be a CCACHE_DIR környezeti változót egy a $(Pipeline.Workspace) alá tartozó elérési útra, és gyorsítótárazza ezt a könyvtárat.

példa:

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

További részletekért lásd Ccache konfigurációs beállításait.

Kikötőmunkás

A Docker-rendszerképek gyorsítótárazása jelentősen csökkentheti a folyamat futtatásához szükséges időt.

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

• Példa a Docker Buildx használatára:

  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
  

Indul

Golang-projektek esetén megadhatja a letöltött csomagokat a go.mod fájlban. Ha a GOCACHE változó még nincs beállítva, állítsa be oda, ahová a gyorsítótárat le szeretné tölteni.

példa:

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

A Gradle beépített gyorsítótárazási támogatásának használata jelentős hatással lehet a buildelési időre. A buildgyorsítótár engedélyezéséhez állítsa a GRADLE_USER_HOME környezeti változót egy $(Pipeline.Workspace) alatti elérési útra, majd vagy futtassa a buildet a --build-cache-vel, vagy adjon hozzá org.gradle.caching=true-at a gradle.properties fájlhoz.

példa:

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

Jegyzet

A gyorsítótárak nem módosíthatók. Ha egy adott kulccsal rendelkező gyorsítótár létrejött egy adott hatókörhöz (például egy ághoz), az nem frissíthető. Ez azt jelenti, hogy ha rögzített kulcsértéket használ, az ugyanazon ág összes későbbi buildje nem fogja tudni frissíteni a gyorsítótárat – még akkor sem, ha a gyorsítótár tartalma megváltozott. Ha rögzített kulcsot használ, mindenképpen adja meg a bemenetet restoreKeys tartalék beállításként.

Maven

A Maven egy helyi adattárat használ a letöltött függőségek és a létrehozott összetevők tárolására. A gyorsítótárazás engedélyezéséhez állítsa be a beállítást maven.repo.local a mappa alatti $(Pipeline.Workspace) elérési útra, és gyorsítótárazza azt.

példa:

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

Ha Maven-feladatothasznál, ügyeljen arra, hogy a MAVEN_OPTS változót is átadja, mert az máskülönben felülíródik.

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

.NET/NuGet

Ha a PackageReferences használatával kezeli a NuGet-függőségeket közvetlenül a projektfájlban, és rendelkezik packages.lock.json fájllal, engedélyezheti a gyorsítótárazást úgy, hogy a NUGET_PACKAGES környezeti változót egy elérési útra állítja $(UserProfile) alatt, és gyorsítótárazhatja ezt a könyvtárat. A függőségek zárolásáról további információt a csomaghivatkozásban talál a projektfájlokban.

Ha több packages.lock.jsonszeretne használni, akkor is használhatja az alábbi példát módosítások nélkül. Az összes packages.lock.json fájl tartalma kivonatolva lesz, és ha az egyik fájl megváltozik, új gyorsítótárkulcs jön létre.

példa:

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

Ez a megközelítés akkor is érvényes a .NET Core-projektekre, ha a projekt packages.lock.json használ a csomagverziók zárolásához. Úgy engedélyezheti ezt, hogy a RestorePackagesWithLockFile fájlban True-t -re állítja, vagy a következő paranccsal: dotnet restore --use-lock-file.

Npm

A gyorsítótárazás engedélyezésének különböző módjai vannak egy Node.js projektben, de az ajánlott módszer az npm megosztott gyorsítótár-könyvtárának gyorsítótárazása. Ezt a könyvtárat az npm felügyeli, és az összes letöltött modul gyorsítótárazott verzióját tartalmazza. A telepítés során az npm először ezt a könyvtárat ellenőrzi (alapértelmezés szerint), ami csökkentheti vagy megszüntetheti a nyilvános npm beállításjegyzékbe vagy a privát beállításjegyzékbe irányuló hálózati hívásokat.

Mivel az npm megosztott gyorsítótár könyvtárának alapértelmezett elérési útja platformonként eltérő, javasoljuk, hogy bírálja felül a környezeti változót npm_config_cache , és állítsa be a $(Pipeline.Workspace). Ez azt is biztosítja, hogy a gyorsítótár tároló- és nem tárolófeladatokból is elérhető legyen.

példa:

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

Ha a projekt nem rendelkezik package-lock.json fájllal, hivatkozzon inkább a package.json fájlra a gyorsítótárkulcs bemenetében.

Borravaló

Mivel npm ci törli a mappát node_modules a modulok konzisztens és megismételhető készletének biztosítása érdekében, kerülje a gyorsítótárazást node_modules a .npm ci

Fonal

Az npm-hez hasonlóan a Yarn is számos módot kínál a telepített csomagok gyorsítótárazására. Az ajánlott módszer a fonal megosztott gyorsítótármappájának gyorsítótárazása. Ezt a könyvtárat a Yarn kezeli, és az összes letöltött csomag gyorsítótárazott verzióját tárolja. A telepítés során a Yarn először ezt a könyvtárat ellenőrzi (alapértelmezés szerint), ami csökkentheti vagy akár meg is szüntetheti a nyilvános vagy privát regisztrációs adatbázisok hálózati hívásait.

példa:

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

Ciklus gyorsítótárazásának beállítása Anaconda-környezetek használatával:

Példa

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/Zeneszerző

A Composert használó PHP-projektek esetében bírálja felül a Composer által használt környezeti változót.

példa:

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

Ismert problémák és visszajelzés

Ha problémái vannak a gyorsítótárazás beállításával a folyamatban, ellenőrizze az adattárban microsoft/azure-pipelines-tasks listáját. Ha nem látja a problémát a listában, hozzon létre egy újat, és adja meg a forgatókönyvével kapcsolatos szükséges információkat.

K&A

K: Törölhetem a gyorsítótárat?

V: A gyorsítótár törlése nem támogatott. A meglévő gyorsítótárakra vonatkozó találatokat azonban elkerülheti, ha hozzáad egy sztringkonstansot (például version2) a gyorsítótárkulcshoz. Módosítsa például a következő gyorsítótárkulcsot:

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

Ehhez:

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

K: Mikor jár le a cache?

A gyorsítótárak hét nap inaktivitás után törlődnek.

K: Mikor lesz feltöltve a gyorsítótár?

A: A rendszer létrehoz egy gyorsítótárat a megadott path és a feladat utolsó lépése után tölti fel. További részletekért tekintse meg a példát.

K: Van-e korlátozás a gyorsítótár méretére?

A: Az egyes gyorsítótárak méretére vagy a szervezeten belüli gyorsítótár teljes méretére nincs kényszerített korlátozás.

Kapcsolódó tartalom

• Csővezeték-artefaktumok közzététele és letöltése

• Az Azure Pipelines biztonságossá tétele

• Engedélyek kezelése