Utiliser plusieurs référentiels dans votre pipeline

Article
06/16/2023

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Les pipelines s’appuient souvent sur plusieurs référentiels qui contiennent la source, les outils, les scripts ou d’autres éléments dont vous avez besoin pour générer votre code. En utilisant plusieurs étapes checkout dans votre pipeline, vous pouvez récupérer (fetch) et extraire d’autres référentiels, outre celui que vous utilisez pour stocker votre pipeline YAML.

Spécifier plusieurs référentiels

Les référentiels peuvent être spécifiés en tant que ressource de référentiel ou inline avec l’étape checkout.

Sont pris en charge les types de référentiels suivants.

Azure Repos Git (git)

Azure DevOps Server (référentiels situés dans la même organisation uniquement)
Azure DevOps Services

GitHub (github)

Azure DevOps Services

GitHubEnterprise (githubenterprise)

Azure DevOps Services

Bitbucket Cloud (bitbucket)

Azure DevOps Services

Important

Seuls les référentiels Azure Repos Git (git) situés dans la même organisation que le pipeline sont pris en charge pour l’extraction de plusieurs référentiels dans Azure DevOps Server.

Notes

Azure Pipelines fournit des paramètres Limiter l’étendue des travaux pour les référentiels Azure Repos Git. Si vous souhaitez extraire des référentiels Azure Repos Git hébergés dans un autre projet, le paramètre Limiter l’étendue des travaux doit être configuré pour autoriser l’accès. Pour plus d’informations, consultez Limiter l’étendue d’autorisation des travaux.

Sont prises en charge les combinaisons suivantes d’étapes checkout.

Aucune étape checkout

Le comportement par défaut est identique au cas de figure où checkout: self constitue la première étape, et le référentiel actuel est extrait.

Une seule étape checkout: none

Aucun référentiel n’est synchronisé ni extrait.

Une seule étape checkout: self

Le référentiel actuel est extrait.

Une seule étape checkout qui n’est pas self ni none

Le référentiel désigné est extrait au lieu de self.

Plusieurs étapes checkout

Chaque référentiel désigné est extrait dans un dossier nommé d’après le référentiel, à moins qu’un autre path ne soit spécifié à l’étape checkout. Pour extraire self comme référentiel, utilisez checkout: self parmi les étapes checkout.

Notes

Lorsque vous effectuez l’extraction de référentiels Git Azure Repos autres que celui contenant le pipeline, il est possible que vous soyez invité à autoriser l’accès à cette ressource avant l’exécution de pipeline pour la première fois. Pour plus d’informations, consultez Pourquoi m’est-il demandé d’autoriser des ressources la première fois que j’essaie d’extraire un autre référentiel ? dans la section FAQ.

Définition de ressources de référentiel

Vous devez utiliser une ressource de référentiel si votre type de référentiel implique une connexion de service ou un autre champ de ressources étendues. Une connexion de service est nécessaire pour les types de référentiels suivants.

Type de référentiel	Connexion du service
Bitbucket Cloud	Bitbucket Cloud
GitHub	GitHub
GitHub Enterprise Server	GitHub Enterprise Server
Les référentiels Azure Repos Git non situés dans la même organisation que votre pipeline	Azure Repos/Team Foundation Server

Il est possible d’utiliser une ressource de référentiel même si le type de référentiel en question n’implique pas de connexion de service, par exemple si une ressource de référentiel a déjà été définie pour les modèles dans un autre référentiel.

Dans l’exemple suivant, trois référentiels sont déclarés en tant que ressources de référentiel. Les ressources de référentiel Azure Repos Git dans une autre organisation, GitHub et Bitbucket Cloud impliquent des connexions de service, qui leur sont spécifiées comme endpoint. Cet exemple comporte quatre étapes checkout, ce qui permet d’extraire les trois référentiels déclarés en tant que ressources de référentiel, ainsi que le référentiel self actuel qui contient le YAML de pipeline.

resources:
  repositories:
  - repository: MyGitHubRepo # The name used to reference this repository in the checkout step
    type: github
    endpoint: MyGitHubServiceConnection
    name: MyGitHubOrgOrUser/MyGitHubRepo
  - repository: MyBitbucketRepo
    type: bitbucket
    endpoint: MyBitbucketServiceConnection
    name: MyBitbucketOrgOrUser/MyBitbucketRepo
  - repository: MyAzureReposGitRepository # In a different organization
    endpoint: MyAzureReposGitServiceConnection
    type: git
    name: OtherProject/MyAzureReposGitRepo

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- checkout: self
- checkout: MyGitHubRepo
- checkout: MyBitbucketRepo
- checkout: MyAzureReposGitRepository

- script: dir $(Build.SourcesDirectory)

Si le référentiel self est nommé CurrentRepo, la commande script produit la sortie CurrentRepo MyAzureReposGitRepo MyBitbucketRepo MyGitHubRepo. Dans cet exemple, le nom donné aux dossiers est celui des référentiels (indiqué par la propriété name dans la ressource de référentiel), car aucun path n’est spécifié à l’étape checkout. Pour plus d’informations sur les noms et emplacements des dossiers de référentiel, consultez la section Chemin d’extraction suivante.

Syntaxe checkout inline

Si votre référentiel n’a pas besoin d’une connexion de service, vous pouvez le déclarer inline avec votre étape checkout.

Notes

Seuls les référentiels Azure Repos Git situés dans la même organisation peuvent utiliser la syntaxe inline. Les référentiels Azure Repos Git qui se trouvent dans une autre organisation et les autres types de référentiels pris en charge impliquent une connexion de service et doivent être déclarés en tant que ressource de référentiel.

steps:
- checkout: self
- checkout: git://MyProject/MyRepo # Azure Repos Git repository in the same organization

Remarque

Dans l'exemple précédent, le référentiel checkout self est spécifié afin d'extraire la source du référentiel associé au pipeline.

Si vous utilisez le référentiel Git Azure Repos par défaut (qui porte le même nom que le projet), utilisez le format - checkout: git://MyRepo/MyRepo

Chemin de l’extraction

À moins qu’un path ne soit spécifié à l’étape checkout, le code source est placé dans un répertoire par défaut. Ce répertoire est différent selon qu’un seul ou plusieurs référentiels sont extraits.

Un seul référentiel : si le travail comporte une seule étape checkout ou ne comprend pas d’étape checkout équivalente à checkout: self, le code source est extrait dans un répertoire appelé s, qui constitue un sous-dossier de (Agent.BuildDirectory). Si (Agent.BuildDirectory) a la valeur C:\agent\_work\1, le code est extrait dans C:\agent\_work\1\s.
Plusieurs référentiels : si le travail comporte plusieurs étapes checkout, le code source est extrait dans les répertoires nommés d’après les référentiels qui constituent un sous-dossier de s dans (Agent.BuildDirectory). Si (Agent.BuildDirectory) est C:\agent\_work\1 et que les référentiels s’appellent tools et code, le code est extrait dans C:\agent\_work\1\s\tools et C:\agent\_work\1\s\code.

Notes

Si aucun path n’est spécifié à l’étape checkout, le nom donné au dossier est celui du référentiel, et non la valeur repository permettant de faire référence au référentiel à l’étape checkout.

Si un path est spécifié pour une étape checkout, il est utilisé, par rapport à (Agent.BuildDirectory).

Notes

Lorsque les chemins par défaut sont utilisés, le fait d’ajouter une deuxième étape de référentiel checkout a pour effet de modifier le chemin par défaut du code du premier référentiel. Par exemple, le code d’un référentiel nommé tools est extrait dans C:\agent\_work\1\s quand tools représente le seul référentiel. Cependant, si un deuxième référentiel est ajouté, tools est extrait dans C:\agent\_work\1\s\tools. Toute étape dépendant du code source qui se trouve à l’emplacement d’origine doit être mise à jour.

Extraction d’une référence spécifique

La branche par défaut est extraite, à moins que vous ne désigniez une référence spécifique.

Si vous utilisez la syntaxe inline, désignez la référence en ajoutant @<ref>. Par exemple :

- checkout: git://MyProject/MyRepo@features/tools # checks out the features/tools branch
- checkout: git://MyProject/MyRepo@refs/heads/features/tools # also checks out the features/tools branch
- checkout: git://MyProject/MyRepo@refs/tags/MyTag # checks out the commit referenced by MyTag.

Lorsque vous utilisez une ressource de référentiel, spécifiez la référence à l’aide de la propriété ref. L’exemple suivant extrait la branche features/tools/ du référentiel désigné.

resources:
  repositories:
  - repository: MyGitHubRepo
    type: github
    endpoint: MyGitHubServiceConnection
    name: MyGitHubOrgOrUser/MyGitHubRepo
    ref: features/tools

steps:
- checkout: MyGitHubRepo

L’exemple suivant utilise des balises pour extraire le commit auquel MyTag fait référence.

resources:
  repositories:
  - repository: MyGitHubRepo
    type: github
    endpoint: MyGitHubServiceConnection
    name: MyGitHubOrgOrUser/MyGitHubRepo
    ref: refs/tags/MyTag

steps:
- checkout: MyGitHubRepo

Déclencheurs

Il est possible de déclencher un pipeline lorsqu’une mise à jour est envoyée (push) au référentiel self ou à l’un des référentiels déclarés en tant que ressources. Cette solution est utile, par exemple, dans les scénarios suivants :

Vous consommez un outil ou une bibliothèque à partir d’un autre référentiel. Vous souhaitez exécuter des tests de votre application chaque fois que l’outil ou la bibliothèque est mis à jour.
Vous conservez votre fichier YAML dans un référentiel distinct du code de l’application. Vous souhaitez déclencher le pipeline chaque fois qu’une mise à jour est envoyée (push) au référentiel de l’application.

Important

Les déclencheurs de ressources de référentiel ne fonctionnent que pour les référentiels Azure Repos Git de la même organisation et lorsque le type de référentiel self est Azure Repos Git. Ils ne sont pas compatibles avec les ressources de référentiel GitHub ni Bitbucket.

batch n’est pas pris en charge dans les déclencheurs de ressources de référentiel.

Si vous ne spécifiez pas de section trigger dans une ressource de référentiel, le pipeline n’est pas déclenché par les modifications apportées à ce référentiel. Dans le cas inverse où une section trigger est définie, le comportement observé est similaire au fonctionnement des déclencheurs CI pour le référentiel self.

Si vous spécifiez une section trigger pour plusieurs ressources de référentiel, toute modification apportée à l’une d’elles déclenche une nouvelle exécution.

Lorsqu’un pipeline est déclenché, Azure Pipelines doit déterminer la version du fichier YAML à utiliser et une version de chaque référentiel à extraire. Si une modification du référentiel self déclenche un pipeline, le commit en question permet d’établir la version du fichier YAML. Dans le cas où le pipeline est déclenché par une modification apportée à une autre ressource de référentiel, c’est la dernière version de YAML dans la branche par défaut du référentiel self qui est retenue.

Lorsqu’une mise à jour de l’un des référentiels déclenche un pipeline, les variables suivantes sont définies en fonction du référentiel en question :

Build.Repository.ID
Build.Repository.Name
Build.Repository.Provider
Build.Repository.Uri
Build.SourceBranch
Build.SourceBranchName
Build.SourceVersion
Build.SourceVersionMessage

Pour le référentiel déclencheur, le commit qui a déclenché le pipeline détermine la version du code extrait. En ce qui concerne les autres référentiels, la version par défaut extraite dépend du ref défini dans YAML pour la ressource de référentiel.

Prenons l’exemple suivant, où le référentiel self contient le fichier YAML, et les référentiels A et B du code source supplémentaire.

trigger:
- main
- feature

resources:
  repositories:
  - repository: A
    type: git
    name: MyProject/A
    ref: main
    trigger:
    - main

  - repository: B
    type: git
    name: MyProject/B
    ref: release
    trigger:
    - main
    - release
steps:
- checkout: self
- checkout: A
- checkout: B

Le tableau suivant montre quelles versions sont extraites pour chaque référentiel par un pipeline utilisant le fichier YAML ci-dessus.

Élément modifié	Pipeline déclenché	Version de YAML	Version de `self`	Version de `A`	Version de `B`
`main` dans `self`	Yes	Commit à partir de `main` qui a déclenché le pipeline	Commit à partir de `main` qui a déclenché le pipeline	La dernière à partir de `main`	La dernière à partir de `release`
`feature` dans `self`	Yes	Commit à partir de `feature` qui a déclenché le pipeline	Commit à partir de `feature` qui a déclenché le pipeline	La dernière à partir de `main`	La dernière à partir de `release`
`main` dans `A`	Yes	La dernière à partir de `main`	La dernière à partir de `main`	Commit à partir de `main` qui a déclenché le pipeline	La dernière à partir de `release`
`main` dans `B`	Yes	La dernière à partir de `main`	La dernière à partir de `main`	La dernière à partir de `main`	Commit à partir de `main` qui a déclenché le pipeline
`release` dans `B`	Yes	La dernière à partir de `main`	La dernière à partir de `main`	La dernière à partir de `main`	Commit à partir de `release` qui a déclenché le pipeline

Vous pouvez également déclencher le pipeline lorsque vous créez ou mettez à jour une demande de tirage (pull request) dans l’un des référentiels. Pour ce faire, déclarez les ressources du référentiel dans les fichiers YAML comme dans les exemples ci-dessus et configurez une stratégie de branche dans le référentiel (Azure Repos uniquement).

Détails du référentiel

Lorsque plusieurs référentiels sont extraits, certaines données sur le référentiel self sont disponibles sous forme de variables. Si vous utilisez des déclencheurs multiréférentiels, certaines de ces variables comportent au contraire des informations sur le référentiel déclencheur. Le détail de tous les référentiels consommés par le travail est disponible sous la forme d’un objet de contexte de modèle appelé resources.repositories.

Par exemple, pour obtenir la référence d’un référentiel autre que self, il est possible d’écrire un pipeline comme suit :

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: |
    echo "Tools version: $TOOLS_REF"

Questions fréquentes (FAQ)

Pourquoi ne puis-je pas extraire un référentiel à partir d’un autre projet ? Cela fonctionnait auparavant.
Pourquoi m’est-il demandé d’autoriser des ressources la première fois que j’essaie d’extraire un autre référentiel ?

Pourquoi ne puis-je pas extraire un référentiel à partir d’un autre projet ? Cela fonctionnait auparavant.

Azure Pipelines fournit un paramètre Limiter l’étendue d’autorisation des travaux au projet actuel qui, lorsqu’il est activé, ne permet pas au pipeline d’accéder aux ressources situées en dehors du projet contenant le pipeline. Ce paramètre peut être défini au niveau de l’organisation ou du projet. Si ce paramètre est activé, vous ne pourrez pas extraire un référentiel dans un autre projet, sauf si vous accordez explicitement l’accès. Pour plus d’informations, consultez Étendue d’autorisation de travail.

Pourquoi m’est-il demandé d’autoriser des ressources la première fois que j’essaie d’extraire un autre référentiel ?

Lorsque vous effectuez l’extraction de référentiels Git Azure Repos autres que celui contenant le pipeline, il est possible que vous soyez invité à autoriser l’accès à cette ressource avant l’exécution de pipeline pour la première fois. Ces invites s’affichent sur la page récapitulative de l’exécution du pipeline.

This pipeline needs permission to access a resource