Partager via

Mise en cache du pipeline

  • Article

Azure DevOps Services

La mise en cache du pipeline peut aider à réduire le temps de génération en permettant aux sorties ou aux dépendances téléchargées à partir d’une exécution d’être réutilisées ultérieurement, ce qui réduit ou évite le coût de recréer ou de télécharger à nouveau les mêmes fichiers. La mise en cache est particulièrement utile dans les scénarios où les mêmes dépendances sont téléchargées au début de chaque exécution. Il s’agit souvent d’un processus fastidieux impliquant des centaines ou des milliers d’appels réseau.

La mise en cache peut être efficace pour améliorer le temps de génération, à condition que le temps de restauration et d’enregistrement du cache soit inférieur au temps de production de la sortie à partir de zéro. En raison de cela, la mise en cache peut ne pas être efficace dans tous les scénarios et peut avoir un impact négatif sur le temps de génération.

Remarque

La mise en cache de pipeline n'est pas prise en charge dans les pipelines de mise en production classiques.

Quand utiliser des artefacts par rapport à la mise en cache

La mise en cache de pipeline et les artefacts de pipeline exécutent des fonctions similaires, mais sont conçus pour différents scénarios et ne doivent pas être utilisés indifféremment.

  • Utilisez des artefacts de pipeline quand vous devez prendre des fichiers spécifiques produits dans un travail et les partager avec d’autres travaux (et que ces autres travaux échouent vraisemblablement sans eux).

  • Utiliser la mise en cache du pipeline lorsque vous souhaitez améliorer le temps de génération en réutilisant les fichiers des exécutions précédentes (et le fait de ne pas avoir ces fichiers n'affectera pas la capacité du travail à s'exécuter).

Remarque

La mise en cache de pipeline et les artefacts de pipeline sont gratuits pour tous les niveaux (gratuits et payants). Pour plus d’informations, consultez Consommation de stockage des artefacts.

Tâche de cache : fonctionnement

La mise en cache est ajoutée à un pipeline à l’aide de la tâche Cache. Cette tâche fonctionne comme toute autre tâche et est ajoutée à la section steps d’un travail.

Lorsqu’une étape de cache est rencontrée pendant une exécution, la tâche restaure le cache en fonction des entrées fournies. Si aucun cache n’est trouvé, l’étape se termine et l’étape suivante du travail est exécutée.

Une fois que toutes les étapes du travail ont été exécutées et en supposant un état de travail réussi, une étape spéciale « Post-travail : Cache » est automatiquement ajoutée et déclenchée pour chaque étape de « restauration du cache » qui n’a pas été ignorée. Cette étape enregistre le cache.

Remarque

Les caches sont immuables, ce qui signifie qu’une fois qu’un cache est créé, son contenu n’est pas modifiable.

Configurer la tâche cache

La tâche de cache a deux arguments obligatoires : key et path :

  • path : chemin du dossier à mettre en cache. Peut être un chemin absolu ou relatif. Les chemins relatifs sont résolus par rapport à $(System.DefaultWorkingDirectory).

Remarque

Vous pouvez utiliser variables prédéfinies pour stocker le chemin d’accès au dossier que vous souhaitez mettre en cache, mais les caractères génériques ne sont pas pris en charge.

  • clé: doit être définie sur l’identificateur du cache que vous souhaitez restaurer ou enregistrer. Les clés sont composées d’une combinaison de valeurs de chaîne, de chemins d’accès de fichier ou de modèles de fichier, où chaque segment est séparé par un caractère |.

  • Chaînes :
    Valeur fixe (comme le nom du cache ou d’un nom d’outil) ou extraite d’une variable d’environnement (par exemple, le système d’exploitation actuel ou le nom du travail actuel)

  • chemins d’accès aux fichiers:
    Chemin d’accès à un fichier spécifique dont le contenu sera haché. Ce fichier doit exister au moment de l’exécution de la tâche. N’oubliez pas que tout segment de clé qui « ressemble à un chemin d’accès de fichier » sera traité comme un chemin d’accès de fichier. En particulier, cela comprend les segments contenant un .. Cela peut entraîner l’échec de la tâche lorsque ce « fichier » n’existe pas.

    Conseil

    Pour éviter qu’un segment de chaîne de type chemin d’accès ne soit traité comme un chemin d’accès de fichier, encapsulez-le avec des guillemets doubles, par exemple : "my.key" | $(Agent.OS) | key.file

  • modèles de fichier:
    Liste séparée par des virgules de modèles génériques de style glob qui doivent correspondre à au moins un fichier. Par exemple:

    • **/yarn.lock : tous les fichiers yarn.lock sous le répertoire des sources
    • */asset.json, !bin/**: tous les fichiers asset.json situés dans un répertoire sous le répertoire sources, à l’exception du répertoire bin

Le contenu d’un fichier identifié par un chemin d’accès ou un modèle de fichier est haché pour produire une clé de cache dynamique. Cela est utile lorsque votre projet comporte des fichiers qui identifient de manière unique ce qui est mis en cache. Par exemple, les fichiers tels que package-lock.json, yarn.lock, Gemfile.lockou Pipfile.lock sont généralement référencés dans une clé de cache, car ils représentent tous un ensemble unique de dépendances.

Les chemins de fichier relatifs ou les modèles de fichier sont résolus par rapport à $(System.DefaultWorkingDirectory).

Exemple:

Voici un exemple montrant comment mettre en cache les dépendances installées par 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

Dans cet exemple, la clé de cache contient trois parties : une chaîne statique (« yarn »), le système d’exploitation sur lequel le travail s’exécute, car ce cache est unique par système d’exploitation et le hachage du fichier yarn.lock qui identifie de manière unique l’ensemble de dépendances dans le cache.

Lors de la première exécution après l’ajout de la tâche, l’étape du cache signale une « absence de cache », car le cache identifié par cette clé n’existe pas. Après la dernière étape, un cache sera créé à partir des fichiers de $(Pipeline.Workspace)/s/.yarn et chargé. Lors de la prochaine exécution, l’étape du cache signale un « accès au cache » et le contenu du cache sera téléchargé et restauré.

Lorsque vous utilisez checkout: self, le référentiel est extrait vers $(Pipeline.Workspace)/s, et votre dossier .yarn réside généralement dans le référentiel même.

Remarque

Pipeline.Workspace est le chemin local de l’agent exécutant votre pipeline où tous les répertoires sont créés. Cette variable a la même valeur que Agent.BuildDirectory.

Veillez à mettre à jour la variable YARN_CACHE_FOLDER si vous utilisez autre chose que checkout: self, car cela doit pointer vers le référentiel où réside .yarn.

Restaurer des clés

restoreKeys pouvez être utilisé si vous souhaitez interroger plusieurs clés exactes ou préfixes de clé. On l’utilise pour revenir à une autre clé dans le cas où une key ne donne pas de résultat. Une clé de restauration recherche une clé par préfixe et génère ainsi la dernière entrée de cache créée. C’est utile si le pipeline ne trouve pas de correspondance exacte, mais veut utiliser une correspondance partielle dans le cache à la place. Pour insérer plusieurs clés de restauration, délimitez-les à l’aide d’une nouvelle ligne pour indiquer la clé de restauration (voir l’exemple pour plus d’informations). Les clés de restauration sont essayées de haut en bas.

Logiciel requis sur l’agent auto-hébergé

Logiciel d’archivage / Plateforme Windows Linux Mac
GNU Tar Obligatoire Obligatoire Non
BSD Tar Non Non Obligatoire
7-Zip Recommandé Non Non

Les exécutables ci-dessus doivent se trouver dans un dossier répertorié dans la variable d’environnement PATH. N’oubliez pas que les agents hébergés sont fournis avec le logiciel inclus, cela s’applique uniquement aux agents auto-hébergés.

Exemple :

Voici un exemple d’utilisation des clés de restauration par 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

Dans cet exemple, la tâche de cache tente de déterminer si la clé existe dans le cache. Si la clé n’existe pas dans le cache, elle tente d’utiliser la première clé de restauration yarn | $(Agent.OS). Cela tente de rechercher toutes les clés qui correspondent exactement à cette clé ou qui ont cette clé comme préfixe. Une correspondance de préfixe peut se produire s’il existe un autre segment de hachage yarn.lock. Par exemple, si la clé suivante yarn | $(Agent.OS) | old-yarn.lock était dans le cache où le old-yarn.lock a généré un hachage différent de yarn.lock, la clé de restauration génère un accès partiel. S’il y a un manque sur la première clé de restauration, il utilise ensuite la clé de restauration suivante yarn qui essaie de trouver une clé qui commence par yarn. Pour les correspondances de préfixe, le résultat produit la clé de cache la plus récente créée.

Remarque

Un pipeline peut avoir une ou plusieurs tâches de mise en cache. Il n’existe aucune limite sur la capacité de stockage de mise en cache, et les travaux et les tâches provenant du même pipeline peuvent accéder et partager le même cache.

Isolation et sécurité du cache

Pour garantir l’isolement entre les caches de différents pipelines et différentes branches, chaque cache appartient à un conteneur logique appelé étendue. Les étendues fournissent une limite de sécurité qui garantit :

  1. Un job d’un pipeline ne peut pas accéder aux caches d’un autre pipeline, et
  2. Un job qui génère une PR dispose d’un accès en lecture aux caches de la branche cible de la PR (pour le même pipeline), mais ne peut pas écrire (créer) de caches dans la portée de la branche cible.

Lorsqu’une étape de cache est rencontrée lors d’une exécution, le cache identifié par la clé est demandé auprès du serveur. Le serveur recherche ensuite un cache avec cette clé dans les étendues accessibles par la tâche et retourne le cache (si disponible). Pendant l’enregistrement du cache (à la fin du travail), un cache est écrit dans l’étendue représentant le pipeline et la branche. Pour plus d’informations, voir ci-dessous.

Exécutions CI, manuelles et planifiées

Portée Lire Écrire
Branche source Oui Oui
branche main Oui Non
branche master Oui Non

Exécutions de demande de tirage

Portée Lire Écrire
Branche source Oui Non
Branche cible Oui Non
Branche intermédiaire (par exemple, refs/pull/1/merge) Oui Oui
branche main Oui Non
branche master Oui Non

Exécutions de duplication de demande de tirage

Branche Lire Écrire
Branche cible Oui Non
Branche intermédiaire (par exemple, refs/pull/1/merge) Oui Oui
branche main Oui Non
branche master Oui Non

Conseil

Étant donné que les caches sont déjà limités à un projet, un pipeline et une branche, il n’est pas nécessaire d’inclure des identificateurs de projet, de pipeline ou de branche dans la clé de cache.

Détermination des conditions pour la restauration du cache

Dans certains scénarios, la restauration réussie du cache doit entraîner l’exécution d’un ensemble différent d’étapes. Par exemple, une étape qui installe les dépendances peut être ignorée si le cache a été restauré. Cela est possible en utilisant l'entrée de tâche cacheHitVar. Si vous définissez cette entrée sur le nom d’une variable d’environnement, la variable est définie sur true en cas d’accès au cache, inexact sur un accès au cache de restauration, sinon elle est définie sur false. Cette variable peut ensuite être référencée dans une condition d’étape ou à partir d’un script.

Dans l’exemple suivant, l’étape install-deps.sh est ignorée lorsque le cache est restauré :

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

Pour les projets Ruby utilisant Bundler, remplacez la variable d’environnement BUNDLE_PATH utilisée par Bundler pour définir le chemin dans lequel Bundler recherche les gemmes.

Exemple :

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 est un cache du compilateur pour C/C++. Pour utiliser Ccache dans votre pipeline, vérifiez que Ccache est installé et éventuellement ajouté à votre PATH (consultez modes d’exécution Ccache). Définissez la variable d’environnement CCACHE_DIR sur un chemin d’accès sous $(Pipeline.Workspace) et mettez en cache ce répertoire.

Exemple :

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

Pour plus d’informations, consultez Paramètres de configuration de Ccache.

docker images

La mise en cache des images Docker réduit considérablement le temps nécessaire à l’exécution de votre pipeline.

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'))
  • clé: (obligatoire) : identificateur unique pour le cache.
  • chemin: (obligatoire) chemin du dossier ou du fichier que vous souhaitez mettre en cache.

Golang

Pour les projets Golang, vous pouvez spécifier les packages à télécharger dans le fichier go.mod. Si votre variable GOCACHE n’est pas déjà définie, définissez-la sur l’emplacement où vous souhaitez que le cache soit téléchargé.

Exemple :

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

L’utilisation de la prise en charge de la mise en cache intégrée de Gradle peut avoir un impact significatif sur le temps de génération. Pour activer le cache de build, définissez la variable d’environnement GRADLE_USER_HOME sur un chemin d’accès sous $(Pipeline.Workspace) et exécutez votre build avec --build-cache ou ajoutez org.gradle.caching=true à votre fichier gradle.properties.

Exemple :

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: les clés de secours si la clé primaire échoue (facultatif)

Remarque

Les caches sont immuables, une fois qu’un cache avec une clé particulière est créé pour une étendue spécifique (branche), le cache ne peut pas être mis à jour. Cela signifie que si la clé est une valeur fixe, toutes les builds suivantes pour la même branche ne pourront pas mettre à jour le cache même si le contenu du cache a changé. Si vous souhaitez utiliser une valeur de clé fixe, vous devez utiliser l’argument restoreKeys comme option de secours.

Maven

Maven dispose d’un référentiel local où il stocke les téléchargements et les artefacts générés. Pour activer, définissez l’option maven.repo.local sur un chemin d’accès sous $(Pipeline.Workspace) et mettez en cache ce dossier.

Exemple :

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

Si vous utilisez une tâche Maven, veillez à passer également la variable MAVEN_OPTS, car sinon elle est remplacée :

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

.NET/NuGet

Si vous utilisez PackageReferences pour gérer les dépendances NuGet directement dans votre fichier projet et que vous disposez d’un fichier packages.lock.json, vous pouvez activer la mise en cache en définissant la variable d’environnement NUGET_PACKAGES sur un chemin d’accès sous $(UserProfile) et en mettant en cache ce répertoire. Consultez référence de package dans les fichiers projet pour plus d’informations sur la façon de verrouiller les dépendances. Si vous souhaitez utiliser plusieurs packages.lock.json, vous pouvez toujours utiliser l’exemple suivant sans apporter de modifications. Le contenu de tous les fichiers packages.lock.json sera haché et si l’un des fichiers est modifié, une nouvelle clé de cache est générée.

Exemple :

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

Cette approche est également valide pour les projets .NET Core si votre projet utilise packages.lock.json pour verrouiller les versions du package. Vous pouvez l’activer en définissant sur dans votre fichier Csproj ou en utilisant la commande suivante : .

Node.js/npm

Il existe différentes façons d’activer la mise en cache dans un projet Node.js, mais la méthode recommandée consiste à mettre en cache le répertoire de cache partagé npm. Ce répertoire est géré par npm et contient une version mise en cache de tous les modules téléchargés. Lors de l’installation, npm vérifie d’abord ce répertoire (par défaut) pour les modules qui peuvent réduire ou éliminer les appels réseau au registre npm public ou à un registre privé.

Comme le chemin d’accès par défaut au répertoire de cache partagé de npm n’est pas identique sur toutes les plateformes, il est recommandé de remplacer la variable d’environnement npm_config_cache par un chemin d’accès sous $(Pipeline.Workspace). Cela garantit également que le cache est accessible à partir des tâches avec conteneur et sans conteneur.

Exemple :

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

Si votre projet n’a pas de fichier package-lock.json, référencez plutôt le fichier package.json dans l’entrée de clé de cache.

Conseil

Étant donné que npm ci supprime le dossier node_modules pour vous assurer qu’un ensemble cohérent et reproductible de modules est utilisé, vous devez éviter de mettre en cache node_modules lors de l’appel de npm ci.

Node.js/Yarn

Comme avec npm, il existe différentes façons de mettre en cache les packages installés avec Yarn. La méthode recommandée consiste à mettre en cache le dossier de cache partagé de Yarn . Ce répertoire est géré par Yarn et contient une version mise en cache de tous les packages téléchargés. Lors de l’installation, Yarn vérifie d’abord ce répertoire (par défaut) pour les modules, ce qui peut réduire ou éliminer les appels réseau aux registres publics ou privés.

Exemple :

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

Configurez la mise en cache de votre pipeline avec des environnements Anaconda :

Exemple

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

Pour les projets PHP utilisant Composer, remplacez la variable d’environnement COMPOSER_CACHE_DIR utilisée par Composer.

Exemple :

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

Problèmes connus et commentaires

Si vous rencontrez des problèmes lors de la configuration de la mise en cache de votre pipeline, consultez la liste des problèmes ouverts dans le dépôt microsoft/azure-pipelines-tasks. Si vous ne voyez pas votre problème répertorié, créez un nouveau problème et fournissez les informations nécessaires sur votre scénario.

Q&R

Q : Puis-je effacer un cache ?

R : L’effacement d’un cache n’est actuellement pas pris en charge. Toutefois, vous pouvez ajouter un littéral de chaîne (tel que version2) à votre clé de cache existante pour modifier la clé d’une manière qui évite les accès sur les caches existants. Par exemple, modifiez la clé de cache suivante à partir de ceci :

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

À cet effet :

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

Q : Quand un cache expire-t-il ?

R : Les caches expirent après sept jours d’absence d’activité.

Q : Quand le cache est-il chargé ?

R : Après la dernière étape de votre pipeline, un cache sera créé à partir de votre cache path et chargé. Pour plus d’informations, consultez l’exemple .

Q : Existe-t-il une limite sur la taille d’un cache ?

R : Il n’existe aucune limite appliquée à la taille des caches individuels ou à la taille totale de tous les caches d’une organisation.