Buforowanie potoku

Azure DevOps Services

Buforowanie potoków może pomóc skrócić czas kompilacji, umożliwiając ponowne utworzenie lub ponowne pobranie tych samych plików z jednego uruchomienia lub pobranie ich ponownie z jednego uruchomienia. Buforowanie jest szczególnie przydatne w scenariuszach, w których te same zależności są pobierane 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 poprawie czasu kompilacji, pod warunkiem, że czas przywracania i zapisania 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.

Uwaga

Buforowanie potoków jest obsługiwane w zadaniach puli agentów zarówno dla potoków YAML, jak i klasycznych. Jednak nie jest obsługiwana w potokach wersji klasycznych.

Kiedy należy używać artefaktów a 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 musisz podjąć określone pliki utworzone w jednym zadaniu i udostępnić je innym zadaniu (i te inne zadania prawdopodobnie nie powiedzą się bez nich).

• Buforowanie potoków jest używane, gdy chcesz poprawić czas kompilacji przez ponowne użycie plików z poprzednich przebiegów (i brak tych plików nie wpłynie na możliwość uruchomienia zadania).

Uwaga

Buforowanie potoków 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: jak to działa

Buforowanie jest dodawane do potoku przy użyciu zadania Pamięci podręcznej. To zadanie działa jak każde inne zadanie i jest dodawane do steps sekcji zadania.

Gdy podczas przebiegu napotkano krok pamięci podręcznej, zadanie przywraca 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 zadania i założeniu pomyślnego stanu zadania specjalny krok "Po zadaniu: pamięć podręczna" zostanie automatycznie dodany i wyzwolony dla każdego kroku "przywracania pamięci podręcznej", 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 jako $(System.DefaultWorkingDirectory).

Uwaga

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

• klucz: 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ą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.

  Napiwek

  Aby uniknąć traktowania segmentu ciągu przypominającego ścieżkę 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 symboli wieloznacznych, która musi być zgodna z co najmniej jednym plikiem. Na 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ą, co jest buforowane. 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ą 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)/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

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 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 "miss 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 $(Pipeline.Workspace)/s/.yarn pliku 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.

W przypadku używania repozytorium checkout: selfjest wyewidencjonowane do $(Pipeline.Workspace)/sfolderu , a .yarn folder zwykle znajduje się w samym repozytorium.

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.

Upewnij się, że zmienna jest YARN_CACHE_FOLDER aktualizowana, jeśli używasz innego elementu niż checkout: self , co powinno wskazywać repozytorium, w którym .yarn się znajduje.

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 odnaleźć dokładnego dopasowania, ale zamiast tego chce użyć częściowej pamięci podręcznej. Aby wstawić wiele kluczy przywracania, 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ą wypróbowane klucze przywracania, będzie od góry do dołu.

Wymagane oprogramowanie na własnym agencie

Archiwizowanie oprogramowania/platformy	Windows	Linux	Mac
GNU Tar	Wymagania	Wymagania	Nie.
BSD Tar	Nie	Nie	Wymagania
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 pochodzą z dołączonego 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 próbuje znaleźć, czy klucz istnieje w pamięci podręcznej. Jeśli klucz nie istnieje w pamięci podręcznej, próbuje użyć pierwszego klucza yarn | $(Agent.OS)przywracania . Próbuje wyszukać wszystkie klucze, które są dokładnie zgodne z tym kluczem 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 old-yarn.lock został zwrócony inny skrót niż yarn.lock, klucz przywracania zwróci częściowe trafienie. Jeśli w pierwszym kluczu przywracania wystąpi błąd, użyje następnego klucza przywracania, który spróbuje znaleźć dowolny klucz yarn rozpoczynający się od yarn. W przypadku trafień prefiks wynik zwraca 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 współużytkować 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 kompilowanie zadania tworzącego żą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). W przypadku 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 szczegółów zobacz poniższą sekcję.

Przebiegi ciągłej integracji, ręczne i zaplanowane

Scope	Przeczytaj	Napisz
Gałąź źródłowa	Tak	Tak
main gałąź	Tak	Nie.
master gałąź	Tak	Nie.

Uruchomienia żądań ściągnięcia

Scope	Przeczytaj	Napisz
Gałąź źródłowa	Tak	Nie.
Gałąź docelowa	Tak	Nie.
Gałąź pośrednia (na przykład refs/pull/1/merge)	Tak	Tak
main gałąź	Tak	Nie.
master gałąź	Tak	Nie.

Uruchomienia rozwidlenia żądania ściągnięcia

Oddział	Przeczytaj	Napisz
Gałąź docelowa	Tak	Nie.
Gałąź pośrednia (na przykład refs/pull/1/merge)	Tak	Tak
main gałąź	Tak	Nie.
master gałąź	Tak	Nie.

Napiwek

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.

Klimatyzacja 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 powoduje, że zmienna ma być ustawiona true w przypadku trafienia pamięci podręcznej w przypadku trafienia inexact pamięci podręcznej klucza przywracania. W przeciwnym razie jest 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 zastąp BUNDLE_PATH zmienną środowiskową używaną przez Bundler, aby ustawić ścieżkę Bundler wyszukując rozwiązania Gems w.

Przykład:

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

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

Ccache (C/C++)

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

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()), not(failed()), ne(variables.CACHE_RESTORED, 'true'))

• key: (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

Użycie 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ę --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: Gradlew stop

• restoreKeys: klucze rezerwowe, jeśli klucz podstawowy zakończy się niepowodzeniem (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

Narzędzie Maven ma repozytorium lokalne, w którym przechowuje pobrane i skompilowane 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 o przekazaniu zmiennejMAVEN_OPTS, ponieważ zostanie ona zastąpiona w przeciwnym razie:

- 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 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 packages.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 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 kontenera i zadań 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, należy odwołać package.json się do pliku w danych wejściowych klucza pamięci podręcznej.

Napiwek

Ponieważ npm ci usuwa node_modules folder, aby upewnić się, że używany jest spójny, powtarzalny zestaw modułów, należy unikać buforowania node_modules podczas wywoływania elementu 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 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 przy użyciu ś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

- bash: |
    sudo chown -R $(whoami):$(id -ng) $(CONDA_CACHE_DIR)
  displayName: Fix CONDA_CACHE_DIR directory permissions

- task: Cache@2
  displayName: Use cached Anaconda environment
  inputs:
    key: 'conda | "$(Agent.OS)" | environment.yml'
    restoreKeys: | 
      python | "$(Agent.OS)"
      python
    path: $(CONDA_CACHE_DIR)
    cacheHitVar: CONDA_CACHE_RESTORED

- script: conda env create --quiet --file environment.yml
  displayName: Create Anaconda environment
  condition: eq(variables.CONDA_CACHE_RESTORED, 'false')

• Windows

  - task: Cache@2
    displayName: Cache Anaconda
    inputs:
      key: 'conda | "$(Agent.OS)" | environment.yml'
      restoreKeys: | 
        python | "$(Agent.OS)"
        python
      path: $(CONDA)/envs
      cacheHitVar: CONDA_CACHE_RESTORED
  
  - script: conda env create --quiet --file environment.yml
    displayName: Create environment
    condition: eq(variables.CONDA_CACHE_RESTORED, 'false')
  

PHP/Composer

W przypadku projektów PHP korzystających z programu 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 swojego problemu na liście, utwórz nowy problem i podaj niezbędne informacje o swoim scenariuszu.

Q&A

.: 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'

Do tego:

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

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

1: Pamięci podręczne wygasają po siedmiu dniach bez działania.

.: Kiedy pamięć podręczna zostanie przekazana?

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.

.: 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.