Buforowanie potoku

  • Artykuł
  • Czas czytania: 13 min

Usługa Azure DevOps Services

Buforowanie potoku może pomóc skrócić czas kompilacji, umożliwiając ponowne użycie danych wyjściowych lub pobranych zależności z jednego uruchomienia, co zmniejsza lub pozwala 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 od samego 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 w poprawie czasu kompilacji, pod warunkiem, że czas przywracania i zapisanie pamięci podręcznej jest krótszy niż czas ponownego wygenerowania danych wyjściowych od podstaw. Z tego powodu 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 należy używać artefaktów i buforowania

Buforowanie potoku 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 (a te inne zadania prawdopodobnie nie będą działać bez nich).

  • Buforowanie potoku jest używane , gdy chcesz poprawić czas kompilacji przez ponowne użycie plików z poprzednich przebiegów (a nie posiadanie tych plików nie będzie miało wpływu na możliwość uruchomienia zadania).

Uwaga

Buforowanie potoku i artefakty potoku są bezpłatne dla wszystkich warstw (bezpłatnych i płatnych). 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 jak każde inne zadanie i jest dodawane do steps sekcji zadania.

Gdy podczas uruchamiania wystąpi krok pamięci podręcznej, zadanie przywróci pamięć podręczną na podstawie podanych danych wejściowych. Jeśli pamięć podręczna nie zostanie znaleziona, 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 ma być buforowany, jednak symbole wieloznaczne nie są obsługiwane.

  • klucz: należy ustawić na 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ść zostanie skrócona. Ten plik musi istnieć w momencie uruchomienia zadania. Należy pamiętać, że każdy segment klucza "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ąć traktowania segmentu ciągu przypominającego ścieżkę jako ścieżki pliku, opakuj go podwójnymi cudzysłowami, na przykład: "my.key" | $(Agent.OS) | key.file

  • Wzorce plików:
    Rozdzielona przecinkami lista wieloznacznych wzorcó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 zidentyfikowanego 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ą buforowane elementy. Na przykład pliki, takie jak package-lock.json, yarn.lock, Gemfile.locklub Pipfile.lock , są często przywołyzowane 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ą rozpoznawane 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 ("yarn"), system operacyjny, na którym jest uruchomione zadanie, ponieważ ta pamięć podręczna jest unikatowa dla 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 na podstawie plików w $(Pipeline.Workspace)/.yarn pliku i przekazanych. W następnym przebiegu 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. Jest to używane do powrotu do innego klucza w przypadku, gdy element key nie daje trafienia. Klucz przywracania wyszuka klucz według prefiksu i w rezultacie zwróci najnowszy utworzony wpis pamięci podręcznej. Jest to przydatne, jeśli potok nie może odnaleźć dokładnego dopasowania, ale chce zamiast tego 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ść, względem 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 są dołączona do oprogramowania. 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 na pierwszym kluczu przywracania brakuje, użyje on 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ć tę samą pamięć podręczną.

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 tworzenie zadania tworzenia żądania ś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ć pamięci podręcznych (tworzenia) 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 wyszukuje pamięć podręczną 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 w przypadku przywracania 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 wartość po trafieniu pamięci podręcznej na trafieniu pamięci podręcznej inexact klucza przywracania, w przeciwnym razie zostanie ustawiona wartość false. Tę zmienną można następnie odwoływać się 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 zastąp BUNDLE_PATH zmienną środowiskową używaną przez Bundler, aby ustawić ścieżkę Bundler będzie szukać rozwiązań Gems w.

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 zainstalowany i opcjonalnie dodany do niego 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 miejsce, w którym 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ę w obszarze $(Pipeline.Workspace) i uruchom kompilację za --build-cache 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 zakończy się niepowodzeniem (opcjonalnie)

Uwaga

Pamięci podręczne są niezmienne, gdy pamięć podręczna o określonym kluczu 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 opcję ścieżki w obszarze $(Pipeline.Workspace) i buforuj maven.repo.local 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 również o przekazaniu zmiennej MAVEN_OPTS , ponieważ zostanie ona zastąpiona w inny sposób:

- task: Maven@4
  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 plik, możesz włączyć buforowanie, ustawiając NUGET_PACKAGES zmienną środowiskową packages.lock.json na ścieżkę w $(UserProfile) obszarze i buforując ten katalog. Aby uzyskać więcej informacji na temat sposobu 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, a jeśli zostanie zmieniony jeden z plików, 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 sprawdza ten katalog jako pierwszy (domyślnie) dla modułów, które mogą zmniejszyć lub wyeliminować wywołania sieciowe do publicznego rejestru npm lub 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 obszarze $(Pipeline.Workspace). Zapewnia to również dostępność pamięci podręcznej z zadań kontenera i niekontenerowych.

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.: Kiedy pamięć podręczna jest przekazywana?

1: Po ostatnim kroku potoku zostanie utworzona pamięć podręczna z pamięci podręcznej path i przekazana. Zobacz przykład , aby uzyskać więcej szczegółów.

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.