Buforowanie potoku

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 w kolejnych uruchomieniach, co zmniejsza lub pozwala uniknąć kosztów ponownego tworzenia lub ponownego pobierania tych samych plików. Buforowanie jest szczególnie przydatne w scenariuszach, w których te same zależności są pobierane over-and-over na początku każdego uruchomienia. Jest to często czasochłonny proces obejmujący setki lub tysiące wywołań sieciowych.

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

Buforowanie jest obecnie obsługiwane w zadaniach ciasnych i wdrażania, ale nie w klasycznych zadaniach wydania.

Kiedy używać artefaktów, a kiedy buforowania

Buforowanie potoku i artefakty potoku pełnią podobne funkcje, ale są przeznaczone dla różnych scenariuszy i nie powinny być używane zamiennie. Ogólnie rzecz biorąc:

  • Artefaktów potoku należy używać, gdy konieczne jest użycie określonych plików wytwarzanych w jednym zadaniu i udostępnienie ich innym zadaniu (a te inne zadania prawdopodobnie nie powiodą się bez nich).

  • Buforowania potoku należy używać, 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ść uruchamiania zadania).

Uwaga

Buforowanie jest obecnie bezpłatne, a pamięci podręczne są przechowywane w usłudze Azure Blob Storage.

Użyj zadania pamięci podręcznej

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

Po napotkaniu kroku pamięci podręcznej podczas uruchamiania 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 zadania. Po uruchomieniu wszystkich kroków zadania i założeniu pomyślnego stanu zadania dla każdego kroku "przywróć pamięć podręczną", który nie został pominięty, jest uruchamiany specjalny krok "Zapisz pamięć podręczną". 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ć jej zawartości.

Konfigurowanie zadania pamięci podręcznej

Zadanie Cache ma dwa wymagane dane wejściowe: i key path .

Wprowadzanie ścieżki

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) . Można użyć wstępnie zdefiniowanych zmiennych, jednak symbole wieloznaczne nie są obsługiwane.

Wprowadzanie klucza

key powinien być ustawiony na identyfikator pamięci podręcznej, którą chcesz przywrócić lub zapisać. Klucze składają się z kombinacji wartości ciągu, ś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 nazwy narzędzia) lub chybienia ze zmiennej środowiskowej (na przykład bieżącego systemu operacyjnego lub bieżącej nazwy 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 dotyczy to segmentów zawierających . . Może to spowodować niepowodzenie zadania, gdy ten "plik" nie istnieje.

    Porada

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

  • Wzorce plików:
    rozdzielana przecinkami lista wzorców symboli wieloznacznych w stylu symboli wieloznacznych, które muszą być zgodne z co najmniej jednym plikiem. Na przykład:

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

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

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

Przykład:

Oto przykład przedstawiający sposób buforowania zależności zainstalowanych przez firmę Yarn:

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/.yarn

steps:
- task: Cache@2
  inputs:
    key: 'yarn | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       yarn | "$(Agent.OS)"
    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, w których jest uruchomione zadanie, ponieważ ta pamięć podręczna jest unikatowa dla każdego systemu operacyjnego, oraz skrót pliku, który jednoznacznie identyfikuje zestaw zależności w pamięci yarn.lock podręcznej.

Przy pierwszym uruchomieniu po dodaniu zadania krok pamięci podręcznej zgłasza "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 pliku i $(Pipeline.Workspace)/.yarn przekazanych. Przy następnym uruchomieniu krok pamięci podręcznej będzie zgłaszać "trafienie pamięci podręcznej", a zawartość pamięci podręcznej zostanie pobrana i przywrócona.

Przywracanie kluczy

restoreKeys Można użyć, jeśli użytkownik chce, aby zapytanie o wiele dokładnie kluczy lub prefiksów klucza. Jest on używany do powrotu do innego klucza w przypadku, gdy element key nie daje trafienia. Klucz przywracania wyszukuje klucz według prefiksu i w rezultacie daje 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ć trafienia częściowej pamięci podręcznej. Aby wstawić wiele kluczy przywracania, po prostu ogranicz je przy użyciu nowego wiersza wskazującego klucz przywracania (zobacz przykład, aby uzyskać więcej szczegółów). Kolejność, względem której będą próbowano przywrócić klucze, 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ą się znaleźć w folderze wymienionym w zmiennej środowiskowej PATH. Należy pamiętać, że hostowany agent jest dołączony do dołączonego oprogramowania. Ma to zastosowanie tylko w przypadku agentów hostowanych samodzielnie.

Przykład:

Oto przykład używania kluczy przywracania przez firmę Yarn:

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/.yarn

steps:
- task: Cache@2
  inputs:
    key: 'yarn | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       yarn | "$(Agent.OS)"
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

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

Uwaga

Potok może mieć co najmniej jedno zadanie buforowania. Nie ma żadnego limitu pojemności magazynu pamięci podręcznej, a zadania i zadania z tego samego potoku mogą uzyskać dostęp do tej samej pamięci podręcznej i współdzielić ją.

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 gwarantuje, że zadanie z jednego potoku nie może uzyskać dostępu do pamięci podręcznych z innego potoku, a zadanie tworzące zadanie ściągnięcie ma dostęp do odczytu do pamięci podręcznych dla gałęzi docelowej tego samego potoku, ale nie może zapisywać (tworzyć) pamięci podręcznych w zakresie gałęzi docelowej.

Gdy krok pamięci podręcznej zostanie napotkany podczas uruchamiania, z serwera jest żądana pamięć podręczna zidentyfikowana przez klucz. 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 w 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, manual, and scheduled runs (Ci, manual, and scheduled runs)

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

Przebiegi żądań ściągnięć

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

Przebiegi rozdęć żądań ściągnięć

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ż zakres pamięci podręcznych jest już ograniczony do projektu, potoku i gałęzi, nie trzeba uwzględniać żadnych identyfikatorów projektu, potoku ani gałęzi w kluczu pamięci podręcznej.

Konserwacja 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 instalowania zależności można pominąć, jeśli pamięć podręczna została przywrócona. Jest to możliwe przy użyciu danych cacheHitVar wejściowych zadania. Ustawienie tych danych wejściowych na nazwę zmiennej środowiskowej spowoduje, że zmienna zostanie ustawiona na po naciśnięciu pamięci podręcznej po trafieniu pamięci podręcznej przy trafieniu pamięci podręcznej klucza przywracania. W przeciwnym razie zostanie ustawiona true inexact wartość false . Następnie można odwoływać się do tej zmiennej w warunku kroku lub w skrypcie.

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 ruby korzystających z narzędzia Bundler zastąp zmienną środowiskową używaną przez program Bundler do ustawienia ścieżki, w ramach których program BUNDLE_PATH Bundler będzie szukać gemów.

Przykład:

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

steps:
- task: Cache@2
  inputs:
    key: 'gems | "$(Agent.OS)" | my.gemspec'
    restoreKeys: | 
      gems | "$(Agent.OS)"
      gems
    path: $(BUNDLE_PATH)
  displayName: Cache gems

- script: bundle install

Ccache (C/C++)

Ccache to pamięć podręczna kompilatora dla języka C/C++. Aby użyć funkcji Ccache w potoku, upewnij się, że jest zainstalowana i opcjonalnie dodana do swojego Ccache PATH potoku (zobacz Tryby uruchamiania ccache). Ustaw CCACHE_DIR zmienną ś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)
  displayName: ccache

Uwaga

W tym przykładzie klucz jest stałą wartością (nazwą systemu operacyjnego), a ponieważ pamięci podręczne są niezmienne, po utworzeniu pamięci podręcznej z tym kluczem dla określonego zakresu (gałęzi) nie można zaktualizować pamięci podręcznej. Oznacza to, że kolejne kompilacje dla tej samej gałęzi nie będą mogły aktualizować pamięci podręcznej, nawet jeśli zawartość pamięci podręcznej uległa zmianie. Ten problem zostanie rozwiązany w nadchodzącej funkcji: 10842: Włączanie kluczy rezerwowych w buforowaniu potoku

Zobacz Ustawienia konfiguracji ccache, aby uzyskać więcej opcji, w tym ustawienia służące do kontrolowania poziomu kompresji.

Obrazy platformy Docker

Buforowanie obrazów platformy Docker znacznie skraca czas uruchamiania potoku.

pool:
  vmImage: 'Ubuntu-16.04'

steps:
  - task: Cache@2
    inputs:
      key: 'docker | cache'
      path: $(Pipeline.Workspace)/docker
      cacheHitVar: DOCKER_CACHE_HIT
    displayName: Cache Docker images
  - script: |
      docker load -i $(Pipeline.Workspace)/docker/cache.tar
    displayName: Restore Docker image
    condition: and(not(canceled()), eq(variables.DOCKER_CACHE_HIT, 'true'))
  - script: |
      mkdir -p $(Pipeline.Workspace)/docker
      docker save -o $(Pipeline.Workspace)/docker/cache.tar cache
    displayName: Save Docker image
    condition: and(not(canceled()), or(failed(), ne(variables.DOCKER_CACHE_HIT, 'true')))

Zastąp caching-docker.yml własnym plikiem YAML potoku.

Golang

W przypadku projektów Golang można określić pakiety do pobrania w pliku go.mod. Jeśli zmienna nie została jeszcze ustawiona, ustaw ją na miejsce, do którego ma zostać GOCACHE 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 zmienną środowiskową na ścieżkę w obszarze i uruchom kompilację za pomocą funkcji GRADLE_USER_HOME lub dodaj ją do $(Pipeline.Workspace) --build-cache org.gradle.caching=true 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. Po utworzeniu pamięci podręcznej z określonym kluczem dla określonego zakresu (gałęzi) nie można zaktualizować pamięci podręcznej. Oznacza to, że jeśli klucz jest wartością stałą, 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ć restoreKeys argumentu jako opcji rezerwowej.

Maven

Maven ma lokalne repozytorium, w którym przechowuje pobrane i sbudowaną artefakty. Aby włączyć tę maven.repo.local opcję, ustaw ścieżkę 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 ona zastąpiona w przeciwnym razie:

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

.NET/NuGet

Jeśli używasz programu do zarządzania zależnościami NuGet bezpośrednio w pliku projektu i masz pliki, możesz włączyć buforowanie, ustawiając zmienną środowiskową na ścieżkę w obszarze i buforowanie PackageReferences packages.lock.json tego NUGET_PACKAGES $(UserProfile) katalogu.

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)"
    path: $(NUGET_PACKAGES)
  displayName: Cache NuGet packages

Porada

Zmienne środowiskowe zawsze zastępują wszystkie ustawienia w NuGet.Config pliku. Jeśli potok zakończył się niepowodzeniem z błędem: , należy utworzyć zmienną potoku dla , aby wskazać nową ścieżkę lokalną na Information, There is a cache miss. NUGET_PACKAGES agencie (exp d:\a\1. ) Potok powinien następnie pobrać zmiany i kontynuować zadanie pomyślnie.

W powyższym przykładzie wskazuje plik blokady $(Build.SourcesDirectory) wygenerowany w projekcie. Zobacz Temat Package reference in project files (Odwołanie do pakietu w plikach projektu), aby uzyskać więcej informacji na temat włączania tworzenia pliku blokady.

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 program npm i zawiera buforowane wersje wszystkich pobranych modułów. Podczas instalacji program npm najpierw sprawdza ten katalog (domyślnie) pod uwagę modułów, które mogą zmniejszyć lub wyeliminować wywołania sieciowe do publicznego rejestr npm lub do rejestru prywatnego.

Ponieważ domyślna ścieżka do katalogu udostępnionej pamięci podręcznej programu npm nie jest taka samana wszystkich platformach, zaleca się zastąpienie zmiennej środowiskowej ścieżką npm_config_cache w obszarze $(Pipeline.Workspace) . Gwarantuje to również, że pamięć podręczna jest dostępna z zadań kontenera i zadań innych niż kontener.

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 pliku, zamiast tego odwołuj się do pliku package-lock.json w danych package.json wejściowych klucza pamięci podręcznej.

Porada

Ponieważ folder jest usuwany w celu zapewnienia spójnego, powtarzalnego zestawu modułów, należy unikać buforowania npm ci node_modules podczas node_modules wywoływania funkcji npm ci .

Node.js/Yarn

Podobnie jak w przypadku npm, istnieją różne sposoby buforowania pakietów zainstalowanych za pomocą usługi Yarn. Zalecanym sposobem jest buforowanie folderu udostępnionej pamięci podręcznej usługiYarn. Ten katalog jest zarządzany przez usługę Yarn i zawiera buforowane wersje wszystkich pobranych pakietów. Podczas instalacji usługa Yarn najpierw sprawdza ten katalog (domyślnie) pod adresami 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)"
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

Python/pip

W przypadku projektów w języku Python, które używają metody pip lub Funkcji, zastąp PIP_CACHE_DIR zmienną środowiskową . Jeśli w polu użyjemy wartości w polu , key zastąp requirements.txt wartością poetry.lock .

Przykład

variables:
  PIP_CACHE_DIR: $(Pipeline.Workspace)/.pip

steps:
- task: Cache@2
  inputs:
    key: 'python | "$(Agent.OS)" | requirements.txt'
    restoreKeys: | 
      python | "$(Agent.OS)"
      python
    path: $(PIP_CACHE_DIR)
  displayName: Cache pip packages

- script: pip install -r requirements.txt

Python/Pipenv

W przypadku projektów języka Python, które używają funkcji Pipenv, zastąp PIPENV_CACHE_DIR zmienną środowiskową .

Przykład

variables:
  PIPENV_CACHE_DIR: $(Pipeline.Workspace)/.pipenv

steps:
- task: Cache@2
  inputs:
    key: 'python | "$(Agent.OS)" | Pipfile.lock'
    restoreKeys: | 
      python | "$(Agent.OS)"
      python
    path: $(PIPENV_CACHE_DIR)
  displayName: Cache pipenv packages

- script: pipenv install

Python/Anaconda

Konfigurowanie buforowania potoku za pomocą środowisk Anaconda

Przykład

variables:
  CONDA_CACHE_DIR: $(Pipeline.Workspace)/.condarc

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

PHP/Composer

W przypadku projektów PHP korzystających z programu Composer zastąp COMPOSER_CACHE_DIR zmienną środowiskową używaną przez program 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ąpią problemy z włączeniem buforowania dla projektu, najpierw sprawdź listę problemów z buforowaniem potoku w repocie microsoft/azure-pipelines-tasks. Jeśli nie widzisz problemu na liście, utwórz nowy problem.

Pytania i odpowiedzi

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

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

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

wprowadź następujące zmiany:

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

Pytanie: Kiedy wygasa pamięć podręczna?

A: Pamięci podręczne wygasają po upływie siedmiu dni od czasu bez aktywności.

Pytanie: Czy istnieje limit rozmiaru pamięci podręcznej?

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