Buforowanie potoku

  • Artykuł
  • Czas czytania: 13 min

Usługa Azure DevOps Services

Buforowanie potoku może pomóc skrócić czas kompilacji, pozwalając na ponowne użycie danych wyjściowych lub pobranych zależności z jednego uruchomienia, co pozwala zmniejszyć lub uniknąć kosztów ponownego utworzenia lub ponownego pobrania tych samych plików. Buforowanie jest szczególnie przydatne w scenariuszach, w których te same zależności są pobierane na początku każdego przebiegu. Jest to często czasochłonny proces obejmujący setki lub tysiące wywołań sieciowych.

Buforowanie może być skuteczne podczas poprawiania czasu kompilacji, pod warunkiem czasu przywrócenia i zapisania pamięci podręcznej jest krótszy niż czas ponownego wygenerowania danych wyjściowych od podstaw. W związku z tym buforowanie może nie być skuteczne we wszystkich scenariuszach i może mieć negatywny wpływ na czas kompilacji.

Buforowanie jest obecnie obsługiwane w zadaniach ciągłej integracji i wdrażania, ale nie w klasycznych zadaniach wydania.

Kiedy używać artefaktów i buforowania

Buforowanie potoków i artefakty potoku wykonują podobne funkcje, ale są przeznaczone dla różnych scenariuszy i nie powinny być używane zamiennie.

  • Użyj artefaktów potoku , gdy trzeba podjąć określone pliki utworzone w jednym zadaniu i udostępnić je innym zadaniu (i te inne zadania prawdopodobnie nie powiedzą się bez nich).

  • Użyj buforowania potoku , gdy chcesz poprawić czas kompilacji przez ponowne użycie plików z poprzednich przebiegów (i nie ma tych plików nie będzie miało wpływu na możliwość uruchomienia zadania).

Uwaga

Buforowanie potoków i artefakty potoku są bezpłatne dla wszystkich warstw (bezpłatne i płatne). Aby uzyskać więcej informacji, zobacz Użycie magazynu artefaktów .

Zadanie pamięci podręcznej

Buforowanie jest dodawane do potoku przy użyciu zadania potoku Cache . To zadanie działa podobnie jak każde inne zadanie i jest dodawane do steps sekcji zadania.

Po napotkaniu kroku pamięci podręcznej podczas przebiegu zadanie przywróci pamięć podręczną na podstawie podanych danych wejściowych. Jeśli nie znaleziono pamięci podręcznej, krok zostanie ukończony i zostanie uruchomiony następny krok w zadaniu. Po uruchomieniu wszystkich kroków w zadaniu i założeniu, że stan zadania zakończył się powodzeniem, dla każdego kroku "przywracania pamięci podręcznej" zostanie uruchomiony specjalny krok "zapisz pamięć podręczną", który nie został pominięty. Ten krok jest odpowiedzialny za zapisywanie pamięci podręcznej.

Uwaga

Pamięci podręczne są niezmienne, co oznacza, że po utworzeniu pamięci podręcznej nie można zmienić jego zawartości.

Konfigurowanie zadania Pamięci podręcznej

Zadanie pamięci podręcznej ma dwa wymagane argumenty: klucz i ścieżka:

  • path: ścieżka folderu do pamięci podręcznej. Może być ścieżką bezwzględną lub względną. Ścieżki względne są rozpoznawane względem $(System.DefaultWorkingDirectory).

Uwaga

Możesz użyć wstępnie zdefiniowanych zmiennych do przechowywania ścieżki do folderu, który chcesz buforować, jednak symbole wieloznaczne nie są obsługiwane.

  • klucz: należy ustawić identyfikator pamięci podręcznej, którą chcesz przywrócić lub zapisać. Klucze składają się z kombinacji wartości ciągów, ścieżek plików lub wzorców plików, gdzie każdy segment jest oddzielony znakiem | .

  • Ciągi:
    Stała wartość (na przykład nazwa pamięci podręcznej lub nazwa narzędzia) lub pobrana ze zmiennej środowiskowej (na przykład bieżąca nazwa systemu operacyjnego lub bieżącego zadania)

  • Ścieżki plików:
    Ścieżka do określonego pliku, którego zawartość będzie skrótem. Ten plik musi istnieć w momencie uruchomienia zadania. Należy pamiętać, że każdy segment klucza, który "wygląda jak ścieżka pliku", będzie traktowany jak ścieżka pliku. W szczególności obejmuje to segmenty zawierające .element . Może to spowodować niepowodzenie zadania, gdy ten "plik" nie istnieje.

    Porada

    Aby uniknąć, aby segment ciągu przypominający ścieżkę był traktowany jak ścieżka pliku, opakuj go podwójnymi cudzysłowami, na przykład: "my.key" | $(Agent.OS) | key.file

  • Wzorce plików:
    Rozdzielona przecinkami lista wieloznacznych wzorów symboli wieloznacznych, która musi być zgodna z co najmniej jednym plikiem. Przykład:

    • **/yarn.lock: wszystkie pliki yarn.lock w katalogu sources
    • */asset.json, !bin/**: wszystkie pliki asset.json znajdujące się w katalogu w katalogu sources, z wyjątkiem katalogu bin

Zawartość dowolnego pliku identyfikowanego przez ścieżkę pliku lub wzorzec pliku jest skrótem w celu utworzenia dynamicznego klucza pamięci podręcznej. Jest to przydatne, gdy projekt zawiera pliki, które jednoznacznie identyfikują, co jest buforowane. Na przykład pliki, takie jak package-lock.json, yarn.lock, Gemfile.locklub Pipfile.lock , są często przywołyne w kluczu pamięci podręcznej, ponieważ wszystkie reprezentują unikatowy zestaw zależności.

Względne ścieżki plików lub wzorce plików są rozwiązywane względem $(System.DefaultWorkingDirectory).

Przykład:

Oto przykład pokazujący sposób buforowania zależności zainstalowanych przez usługę 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

W tym przykładzie klucz pamięci podręcznej zawiera trzy części: ciąg statyczny ("przędza"), system operacyjny, na którym działa zadanie, ponieważ ta pamięć podręczna jest unikatowa dla każdego systemu operacyjnego, a skrót yarn.lock pliku, który jednoznacznie identyfikuje zestaw zależności w pamięci podręcznej.

W pierwszym uruchomieniu po dodaniu zadania krok pamięci podręcznej zgłosi "chybienie pamięci podręcznej", ponieważ pamięć podręczna zidentyfikowana przez ten klucz nie istnieje. Po ostatnim kroku pamięć podręczna zostanie utworzona z plików w pliku $(Pipeline.Workspace)/.yarn i przekazana. W następnym uruchomieniu krok pamięci podręcznej zgłosi "trafienie pamięci podręcznej", a zawartość pamięci podręcznej zostanie pobrana i przywrócona.

Uwaga

Pipeline.Workspace to ścieżka lokalna agenta uruchamiającego potok, w którym są tworzone wszystkie katalogi. Ta zmienna ma taką samą wartość jak Agent.BuildDirectory.

Przywracanie kluczy

restoreKeys można użyć, jeśli chcesz wykonać zapytanie względem wielu dokładnych kluczy lub prefiksów kluczy. Służy do powrotu do innego klucza w przypadku, gdy element key nie daje trafienia. Klucz przywracania wyszukuje klucz według prefiksu i w rezultacie zwraca najnowszy utworzony wpis pamięci podręcznej. Jest to przydatne, jeśli potok nie może znaleźć dokładnego dopasowania, ale zamiast tego chce użyć częściowej pamięci podręcznej. Aby wstawić wiele kluczy przywracania, po prostu ogranicz je przy użyciu nowego wiersza, aby wskazać klucz przywracania (zobacz przykład, aby uzyskać więcej szczegółów). Kolejność, w której będą sprawdzane klucze przywracania, będzie od góry do dołu.

Wymagane oprogramowanie na własnym agencie

Archiwizowanie oprogramowania/platformy Windows Linux Mac
GNU Tar Wymagane Wymagane Nie
BSD Tar Nie Nie Wymagane
7-Zip Zalecane Nie Nie

Powyższe pliki wykonywalne muszą znajdować się w folderze wymienionym w zmiennej środowiskowej PATH. Należy pamiętać, że hostowani agenci mają dołączone oprogramowanie. Dotyczy to tylko własnych agentów.

Przykład:

Oto przykład użycia kluczy przywracania przez usługę 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

W tym przykładzie zadanie pamięci podręcznej podejmie próbę znalezienia, czy klucz istnieje w pamięci podręcznej. Jeśli klucz nie istnieje w pamięci podręcznej, spróbuje użyć pierwszego klucza yarn | $(Agent.OS)przywracania . Spowoduje to próbę wyszukania wszystkich kluczy, które dokładnie pasują do tego klucza lub ma ten klucz jako prefiks. W przypadku innego yarn.lock segmentu skrótu może wystąpić trafienie prefiksu. Jeśli na przykład następujący klucz yarn | $(Agent.OS) | old-yarn.lock znajdował się w pamięci podręcznej, w której stary yarn.lock dał inny skrót niż yarn.lock, klucz przywracania zwróci częściowe trafienie. Jeśli brakuje pierwszego klucza przywracania, użyje następnego klucza przywracania, który spróbuje znaleźć dowolny klucz yarn rozpoczynający się od yarn. W przypadku trafień prefiksu wynik zwróci ostatnio utworzony klucz pamięci podręcznej w wyniku.

Uwaga

Potok może mieć co najmniej jedno zadanie buforowania. Nie ma limitu pojemności magazynu buforowania, a zadania i zadania z tego samego potoku mogą uzyskiwać dostęp do tej samej pamięci podręcznej i udostępniać je.

Izolacja i zabezpieczenia pamięci podręcznej

Aby zapewnić izolację między pamięciami podręcznymi z różnych potoków i różnych gałęzi, każda pamięć podręczna należy do kontenera logicznego nazywanego zakresem. Zakresy zapewniają granicę zabezpieczeń, która zapewnia, że zadanie z jednego potoku nie może uzyskać dostępu do pamięci podręcznych z innego potoku, a zadanie tworzące żądanie ściągnięcia ma dostęp do odczytu do pamięci podręcznych dla gałęzi docelowej żądania ściągnięcia (dla tego samego potoku), ale nie może zapisywać (tworzyć) pamięci podręcznych w zakresie gałęzi docelowej.

Gdy podczas uruchamiania wystąpi krok pamięci podręcznej, pamięć podręczna zidentyfikowana przez klucz jest żądana z serwera. Następnie serwer szuka pamięci podręcznej z tym kluczem z zakresów widocznych dla zadania i zwraca pamięć podręczną (jeśli jest dostępna). Podczas zapisywania pamięci podręcznej (na końcu zadania) pamięć podręczna jest zapisywana w zakresie reprezentującym potok i gałąź. Aby uzyskać więcej informacji, zobacz poniżej.

Ciągła integracja, ręczne i zaplanowane przebiegi

Zakres Odczyt Zapisywanie
Gałąź źródłowa Tak Tak
Gałąź main Tak Nie

Uruchomienia żądań ściągnięcia

Zakres Odczyt Zapisywanie
Gałąź źródłowa Tak Nie
Gałąź docelowa Tak Nie
Gałąź pośrednia (na przykład refs/pull/1/merge) Tak Tak
Gałąź main Tak Nie

Uruchomienia rozwidlenia żądania ściągnięcia

Odgałęzienie Odczyt Zapisywanie
Gałąź docelowa Tak Nie
Gałąź pośrednia (na przykład refs/pull/1/merge) Tak Tak
Gałąź main Tak Nie

Porada

Ponieważ pamięci podręczne są już ograniczone do projektu, potoku i gałęzi, nie ma potrzeby dołączania żadnych identyfikatorów projektu, potoku lub gałęzi w kluczu pamięci podręcznej.

Kondycja przy przywracaniu pamięci podręcznej

W niektórych scenariuszach pomyślne przywrócenie pamięci podręcznej powinno spowodować uruchomienie innego zestawu kroków. Na przykład krok, który instaluje zależności, można pominąć, jeśli pamięć podręczna została przywrócona. Jest to możliwe przy użyciu danych wejściowych cacheHitVar zadania. Ustawienie tych danych wejściowych na nazwę zmiennej środowiskowej spowoduje, że zmienna zostanie ustawiona na true trafienie pamięci podręcznej w inexact przypadku trafienia pamięci podręcznej klucza przywracania. W przeciwnym razie zostanie ustawiona wartość false. Tę zmienną można następnie odwołać w warunku kroku lub z poziomu skryptu.

W poniższym przykładzie install-deps.sh krok jest pomijany po przywróceniu pamięci podręcznej:

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

W przypadku projektów języka Ruby korzystających z narzędzia Bundler przesłoń BUNDLE_PATH zmienną środowiskową używaną przez bundler do ustawienia ścieżki Bundler będzie szukać rozwiązania Gems in.

Przykład:

variables:
  BUNDLE_PATH: $(Pipeline.Workspace)/.bundle

steps:
- task: Cache@2
  displayName: Bundler caching
  inputs:
    key: 'gems | "$(Agent.OS)" | Gemfile.lock'
    restoreKeys: | 
      gems | "$(Agent.OS)"
      gems
    path: $(BUNDLE_PATH)

Ccache (C/C++)

Ccache to pamięć podręczna kompilatora dla języka C/C++. Aby użyć usługi Ccache w potoku, upewnij się, że Ccache jest zainstalowana i opcjonalnie dodana do elementu PATH (zobacz Tryby uruchamiania usługi Ccache). Ustaw zmienną CCACHE_DIR środowiskową na ścieżkę w obszarze $(Pipeline.Workspace) i buforuj ten katalog.

Przykład:

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
  inputs:
    key: 'ccache | "$(Agent.OS)"'
    path: $(CCACHE_DIR)
    restoreKeys: | 
      ccache | "$(Agent.OS)"
  displayName: ccache

Aby uzyskać więcej informacji, zobacz Ustawienia konfiguracji usługi Ccache .

Obrazy platformy Docker

Buforowanie obrazów platformy Docker znacznie skraca czas potrzebny na uruchomienie potoku.

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()), or(failed(), ne(variables.CACHE_RESTORED, 'true')))
  • klucz: (wymagane) — unikatowy identyfikator pamięci podręcznej.
  • path: (wymagane) — ścieżka folderu lub pliku, który chcesz buforować.

Golang

W przypadku projektów Języka Golang można określić pakiety do pobrania w pliku go.mod . GOCACHE Jeśli zmienna nie jest jeszcze ustawiona, ustaw ją na lokalizację, w której ma zostać pobrana pamięć podręczna.

Przykład:

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

Korzystanie z wbudowanej obsługi buforowania narzędzia Gradle może mieć znaczący wpływ na czas kompilacji. Aby włączyć pamięć podręczną kompilacji, ustaw GRADLE_USER_HOME zmienną środowiskową na ścieżkę poniżej $(Pipeline.Workspace) i uruchom kompilację --build-cache za pomocą polecenia lub dodaj org.gradle.caching=true do gradle.properties pliku.

Przykład:

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: Build
  • restoreKeys: klucze rezerwowe, jeśli klucz podstawowy ulegnie awarii (opcjonalnie)

Uwaga

Pamięci podręczne są niezmienne, gdy pamięć podręczna z określonym kluczem zostanie utworzona dla określonego zakresu (gałęzi), nie można zaktualizować pamięci podręcznej. Oznacza to, że jeśli klucz jest stałą wartością, wszystkie kolejne kompilacje dla tej samej gałęzi nie będą mogły zaktualizować pamięci podręcznej, nawet jeśli zawartość pamięci podręcznej uległa zmianie. Jeśli chcesz użyć stałej wartości klucza, musisz użyć argumentu restoreKeys jako opcji rezerwowej.

Maven

Maven ma lokalne repozytorium, w którym przechowuje pobrane i utworzone artefakty. Aby włączyć, ustaw maven.repo.local opcję ścieżki w obszarze $(Pipeline.Workspace) i buforuj ten folder.

Przykład:

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

Jeśli używasz zadania Maven, pamiętaj, aby przekazać również zmienną MAVEN_OPTS , ponieważ zostanie zastąpiona w przeciwnym razie:

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

.NET/NuGet

Jeśli używasz PackageReferences do zarządzania zależnościami NuGet bezpośrednio w pliku projektu i masz packages.lock.json plik, możesz włączyć buforowanie, ustawiając NUGET_PACKAGES zmienną środowiskową na ścieżkę w obszarze $(UserProfile) i buforując ten katalog. Aby uzyskać więcej informacji na temat blokowania zależności, zobacz Informacje o pakiecie w plikach projektu . Jeśli chcesz użyć wielu pakietów.lock.json, nadal możesz użyć poniższego przykładu bez wprowadzania żadnych zmian. Zawartość wszystkich plików packages.lock.json zostanie skrócona i jeśli jeden z plików zostanie zmieniony, zostanie wygenerowany nowy klucz pamięci podręcznej.

Przykład:

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

Istnieją różne sposoby włączania buforowania w projekcie Node.js, ale zalecanym sposobem jest buforowanie katalogu udostępnionej pamięci podręcznej npm. Ten katalog jest zarządzany przez narzędzie npm i zawiera buforowaną wersję wszystkich pobranych modułów. Podczas instalacji narzędzie npm najpierw sprawdza ten katalog (domyślnie) dla modułów, które mogą zmniejszyć lub wyeliminować wywołania sieciowe do publicznego rejestru npm lub do rejestru prywatnego.

Ponieważ domyślna ścieżka do katalogu udostępnionej pamięci podręcznej npm nie jest taka sama na wszystkich platformach, zaleca się zastąpienie npm_config_cache zmiennej środowiskowej ścieżką w ścieżce poniżej $(Pipeline.Workspace). Zapewnia to również dostępność pamięci podręcznej z zadań kontenera i innych niż kontenery.

Przykład:

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

Jeśli projekt nie ma package-lock.json pliku, odwołaj package.json się do pliku w danych wejściowych klucza pamięci podręcznej.

Porada

Ponieważ npm ci usuwa folder w node_modules celu zapewnienia, że używany jest spójny, powtarzalny zestaw modułów, należy unikać buforowania node_modules podczas wywoływania metody npm ci.

Node.js/Yarn

Podobnie jak w przypadku narzędzia npm, istnieją różne sposoby buforowania pakietów zainstalowanych za pomocą narzędzia Yarn. Zalecanym sposobem jest buforowanie folderu udostępnionej pamięci podręcznej usługi Yarn. Ten katalog jest zarządzany przez usługę Yarn i zawiera buforowaną wersję wszystkich pobranych pakietów. Podczas instalacji usługa Yarn najpierw sprawdza ten katalog (domyślnie) dla modułów, co może zmniejszyć lub wyeliminować wywołania sieciowe do rejestrów publicznych lub prywatnych.

Przykład:

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

Skonfiguruj buforowanie potoku za pomocą środowisk Anaconda:

Przykład

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

- 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

W przypadku projektów PHP używających narzędzia Composer zastąp zmienną COMPOSER_CACHE_DIRśrodowiskową używaną przez composer.

Przykład:

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

Znane problemy i opinie

Jeśli występują problemy z konfigurowaniem buforowania dla potoku, sprawdź listę otwartych problemów w microsoft/azure-pipelines-tasks repozytorium. Jeśli nie widzisz problemu na liście, utwórz nowy i podaj niezbędne informacje o scenariuszu.

Pytania&i pytania

Pyt.: Czy mogę wyczyścić pamięć podręczną?

1: Wyczyszczenie pamięci podręcznej nie jest obecnie obsługiwane. Można jednak dodać literał ciągu (na version2przykład ) do istniejącego klucza pamięci podręcznej, aby zmienić klucz w sposób, który pozwala uniknąć trafień w istniejących pamięciach podręcznych. Na przykład zmień następujący klucz pamięci podręcznej z tego:

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

wprowadź następujące zmiany:

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

Pyt.: Kiedy pamięć podręczna wygaśnie?

1: Pamięci podręczne wygasają po siedmiu dniach braku aktywności.

Pyt.: Czy istnieje limit rozmiaru pamięci podręcznej?

1: Nie ma wymuszonego limitu rozmiaru poszczególnych pamięci podręcznych ani całkowitego rozmiaru wszystkich pamięci podręcznych w organizacji.