Utiliser plusieurs référentiels dans votre pipeline

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

Pipelines s’appuient souvent sur plusieurs référentiels qui contiennent du code source, des outils, des 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 repository ou inline avec l’étape checkout.

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

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

Définition de ressources de référentiel

Vous devez utiliser une ressource repository si votre type de référentiel nécessite 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.

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. Dépôt Git Azure Repos dans une autre organisation, GitHub et Bitbucket Cloud les ressources du référentiel nécessitent des connexions service qui sont spécifiées comme endpoint pour ces ressources de référentiel. 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.

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

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

Référentiel d’espace de travail

Lorsque plusieurs étapes checkout (et différents chemins d’accès pour chacun) sont utilisées dans votre pipeline, vous pouvez utiliser le répertoire racine de l’un des référentiels comme répertoire de travail par défaut. Si c’est le cas, vous pouvez définir l’entrée workspaceRepo sur true pour l’étape de checkout associée.

- checkout: git://project/first
  path: repo/first-repo

- checkout: git://project/second
  path: repo/second-repo
  workspaceRepo: true

- pwsh: pwd
# Expected output: $(Pipeline.Workspace)/repo/second-repo

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.

Paramétrer une branche avec une syntaxe inline

Définissez un paramètre runtime et référencez-le avec une expression de modèle dans la valeur d’extraction inline :

parameters:
  - name: branch
    type: string
    default: 'main'

steps:
  - checkout: git://MyProject/MyRepo@${{ parameters.branch }}

Paramétrer une branche avec une ressource de référentiel

Utilisez la ref propriété sur une ressource de référentiel pour définir la branche à partir d’un paramètre :

parameters:
  - name: branch
    type: string
    default: 'main'

resources:
  repositories:
    - repository: MyRepo
      type: git
      name: MyProject/MyRepo
      ref: ${{ parameters.branch }}

steps:
  - checkout: MyRepo

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 tags pour extraire la validation référencée par MyTag.

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

steps:
- checkout: MyGitHubRepo

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

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 d'un autre project ? 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 d'un autre project ? Cela fonctionnait auparavant.

Azure Pipelines fournit une étendue d'autorisation de travail Limiter le paramètre actuel project, qui, lorsqu'il est activé, n'autorise pas le pipeline à access ressources en dehors du project qui contient le pipeline. Ce paramètre peut être défini au niveau de l’organisation ou du project. Si ce paramètre est activé, vous ne pourrez pas extraire un référentiel dans une autre project, sauf si vous accordez explicitement access. Pour plus d’informations, consultez 'étendue d’autorisationJob.

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 consultez Azure Repos référentiels Git autres que celui contenant le pipeline, vous pouvez être invité à autoriser access à cette ressource avant l’exécution du pipeline pour la première fois. Ces invites s’affichent sur la page récapitulative de l’exécution du pipeline.

Choisissez Afficher ou Autoriser des ressources, puis suivez les invites pour autoriser les ressources.

Pour plus d’informations, consultez Résolution des problèmes d’autorisation d’un pipeline YAML.