Auschecken mehrerer Repositorys in Ihrer Pipeline

Artikel
06/16/2023

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

Pipelines basieren häufig auf mehreren Repositorys, die Quellen, Tools, Skripts oder andere Elemente enthalten, die Sie zum Erstellen Ihres Codes benötigen. Durch die Verwendung mehrerer checkout-Schritte in Ihrer Pipeline können Sie neben dem Repository, in dem Sie Ihre YAML-Pipeline speichern, auch weitere Repositorys abrufen und auschecken.

Angeben mehrerer Repositorys

Repositorys können als Repositoryressource oder inline mit dem checkout-Schritt angegeben werden.

Die folgenden Repositorytypen werden unterstützt.

Azure Repos Git (git)

Azure DevOps Server (beschränkt auf Repositorys in derselben Organisation)
Azure DevOps Services

GitHub (github)

Azure DevOps Services

GitHubEnterprise (githubenterprise)

Azure DevOps Services

Bitbucket Cloud (bitbucket)

Azure DevOps Services

Wichtig

Für das Auschecken mehrerer Repositorys in Azure DevOps Server werden nur Azure Repos Git-Repositorys (git) in derselben Organisation wie die Pipeline unterstützt.

Hinweis

Azure Pipelines bietet Einstellungen zum Einschränken des Auftragsbereichs für Azure Repos Git-Repositorys. Um Azure Repos Git-Repositorys auszuchecken, die in einem anderen Projekt gehostet werden, müssen die Einstellungen zum Einschränken des Auftragsbereichs so konfiguriert sein, dass der Zugriff erlaubt ist. Weitere Informationen finden Sie unter Einschränken des Auftragsautorisierungsbereichs.

Die folgenden Kombinationen von checkout-Schritten werden unterstützt.

Keine checkout-Schritte

Das Standardverhalten ist so, als wäre checkout: self der erste Schritt, und das aktuelle Repository wird ausgecheckt.

Ein einzelner checkout: none-Schritt

Es werden keine Repositorys synchronisiert oder ausgecheckt.

Ein einzelner checkout: self-Schritt

Das aktuelle Repository wird ausgecheckt.

Ein einzelner checkout-Schritt, bei dem es sich nicht um self oder none handelt

Anstelle von self wird das angegebene Repository ausgecheckt.

Mehrere checkout-Schritte

Jedes angegebene Repository wird in einen nach dem Repository benannten Ordner ausgecheckt, es sei denn, im checkout-Schritt wird ein anderer path angegeben. Um self als eines der Repositorys auszuchecken, verwenden Sie checkout: self als einen der checkout-Schritte.

Hinweis

Wenn Sie andere Azure Repos Git-Repositorys als das auschecken, das die Pipeline enthält, werden Sie möglicherweise aufgefordert, den Zugriff auf diese Ressource zu autorisieren, bevor die Pipeline zum ersten Mal ausgeführt wird. Weitere Informationen finden Sie unter Warum werde ich aufgefordert, Ressourcen zu autorisieren, wenn ich zum ersten Mal versuche, ein anderes Repository auszuchecken? im Abschnitt Häufig gestellte Fragen.

Definition einer Repositoryressource

Sie müssen eine Repositoryressource verwenden, wenn Ihr Repositorytyp eine Dienstverbindung oder ein anderes erweitertes Ressourcenfeld benötigt. Die folgenden Repositorytypen erfordern eine Dienstverbindung.

Repositorytyp	Dienstverbindung
Bitbucket-Cloud	Bitbucket-Cloud
GitHub	GitHub
GitHub Enterprise Server	GitHub Enterprise Server
Azure Repos Git-Repositorys in einer anderen Organisation als Ihre Pipeline	Azure Repos/Team Foundation Server

Sie können eine Repositoryressource auch dann verwenden, wenn für Ihren Repositorytyp keine Dienstverbindung erforderlich ist, z. B. wenn Sie bereits eine Repositoryressource für Vorlagen in einem anderen Repository definiert haben.

Im folgenden Beispiel werden drei Repositorys als Repositoryressourcen deklariert. Die Repositoryressourcen für ein Azure Repos Git-Repository in einer anderen Organisation, für GitHub und Bitbucket Cloud erfordern Dienstverbindungen, die als endpoint für diese Repositoryressourcen angegeben werden. Dieses Beispiel umfasst vier checkout-Schritte, in denen die drei als Repositoryressourcen deklarierten Repositorys zusammen mit dem aktuellen self-Repository ausgecheckt werden, das die Pipeline-YAML enthält.

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)

Wenn das self-Repository den Namen CurrentRepo aufweist, erzeugt der Befehl script die folgende Ausgabe: CurrentRepo MyAzureReposGitRepo MyBitbucketRepo MyGitHubRepo. In diesem Beispiel werden die Namen der Repositorys (wie durch die name-Eigenschaft in der Repositoryressource angegeben) für die Ordner verwendet, da im Check-Out-Schritt kein path angegeben ist. Weitere Informationen zu Repositoryordnernamen und Speicherorten finden Sie im folgenden Abschnitt zum Check-Out-Pfad.

Auschecken mit Inline-Syntax

Wenn für Ihr Repository keine Dienstverbindung erforderlich ist, können Sie es inline mit Ihrem checkout-Schritt deklarieren.

Hinweis

Nur Azure Repos Git-Repositorys in derselben Organisation können die Inline-Syntax verwenden. Azure Repos Git-Repositorys in einer anderen Organisation und andere unterstützte Repositorytypen erfordern eine Dienstverbindung und müssen als Repositoryressource deklariert werden.

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

Hinweis

Im vorherigen Beispiel wird das self-Checkout-Repository angegeben, um die Quelle des mit der Pipeline verbundenen Repositorys auszuchecken.

Wenn Sie das standardmäßige Azure Repos Git-Repository verwenden (das denselben Namen wie das Projekt hat), verwenden Sie das Format - checkout: git://MyProject/MyRepo.

Check-Out-Pfad

Wenn im checkout-Schritt kein path angegeben ist, wird der Quellcode in einem Standardverzeichnis abgelegt. Dieses Verzeichnis ist unterschiedlich, je nachdem, ob Sie ein einzelnes Repository oder mehrere Repositorys auschecken.

Einzelnes Repository: Wenn Sie in Ihrem Auftrag nur einen einzigen checkout-Schritt oder keinen Check-Out-Schritt verwenden (was checkout: self entspricht), wird Ihr Quellcode in ein Verzeichnis namens s ausgecheckt, das sich in einem Unterordner von (Agent.BuildDirectory) befindet. Wenn (Agent.BuildDirectory) als C:\agent\_work\1 angegeben ist, wird Ihr Code in C:\agent\_work\1\sausgecheckt.
Mehrere Repositorys: Wenn Sie mehrere checkout-Schritte in Ihrem Auftrag verwenden, wird Ihr Quellcode in Verzeichnisse ausgecheckt, die nach den Repositorys als Unterordner von s in (Agent.BuildDirectory) benannt sind. Wenn (Agent.BuildDirectory) als C:\agent\_work\1 angegeben ist und die Namen Ihrer Repositorys tools und code lauten, wird Ihr Code in C:\agent\_work\1\s\tools und C:\agent\_work\1\s\code ausgecheckt.

Hinweis

Wenn im checkout-Schritt kein path angegeben wird, wird anstelle des repository-Werts, der im checkout-Schritt zum Verweis auf das Repository verwendet wird, der Name des Repositorys für den Ordner verwendet.

Wenn ein path für einen checkout-Schritt angegeben ist, wird dieser Pfad relativ zu (Agent.BuildDirectory) verwendet.

Hinweis

Wenn Sie Standardpfade verwenden, ändert das Hinzufügen eines zweiten checkout-Schritts für ein Repository den Standardpfad für den Code des ersten Repositorys. Zum Beispiel würde der Code für ein Repository mit dem Namen tools nach C:\agent\_work\1\s ausgecheckt werden, wenn tools das einzige Repository ist. Wird jedoch ein zweites Repository hinzugefügt, wird tools nach C:\agent\_work\1\s\tools ausgecheckt. Wenn Schritte davon abhängen, dass sich der Quellcode am ursprünglichen Speicherort befindet, müssen diese Schritte aktualisiert werden.

Auschecken per Verweis

Sofern Sie keinen spezifischen Verweis angeben, wird der Standardbranch ausgecheckt.

Bei Verwendung der Inline-Syntax geben Sie den Verweis durch Anhängen von @<ref> an. Beispiel:

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

Wenn Sie eine Repositoryressource verwenden, geben Sie den Verweis mithilfe der Eigenschaft ref an. Im folgenden Beispiel wird der Branch features/tools/ des angegebenen Repositorys ausgecheckt.

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

steps:
- checkout: MyGitHubRepo

Im folgenden Beispiel werden Tags verwendet, um den Commit auszuchecken, auf den über MyTag verwiesen wird.

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

steps:
- checkout: MyGitHubRepo

Trigger

Sie können eine Pipeline auslösen, wenn ein Update in das Repository self oder in eines der als Ressourcen deklarierten Repositorys gepusht wird. Dies ist zum Beispiel in den folgenden Szenarien nützlich:

Sie nutzen ein Tool oder eine Bibliothek aus einem anderen Repository. Sie möchten Tests für Ihre Anwendung ausführen, sobald das Tool oder die Bibliothek aktualisiert wird.
Sie bewahren Ihre YAML-Datei in einem Repository auf, das vom Anwendungscode getrennt ist. Sie möchten die Pipeline immer dann auslösen, wenn ein Update in das Anwendungsrepository gepusht wird.

Wichtig

Auslöser für Repository-Ressourcen funktionieren nur für Azure Repos Git-Repositories in derselben Organisation und wenn der self Repository-Typ Azure Repos Git ist. Sie funktionieren nicht für GitHub- oder Bitbucket-Repositoryressourcen.

batch wird in Triggern für Repositoryressourcen nicht unterstützt.

Wenn Sie keinen trigger-Abschnitt in einer Repositoryressource angeben, wird die Pipeline nicht durch Änderungen an diesem Repository ausgelöst. Wenn Sie einen trigger-Abschnitt angeben, erfolgt die Auslösung ähnlich wie bei den CI-Triggern für das self-Repository.

Wenn Sie einen trigger-Abschnitt für mehrere Repositoryressourcen angeben, wird bei einer Änderung einer dieser Ressourcen eine neue Ausführung gestartet.

Wenn eine Pipeline ausgelöst wird, muss Azure Pipelines die Version der zu verwendenden YAML-Datei und eine Version für jedes Repository bestimmen, das ausgecheckt werden soll. Wenn eine Änderung am self-Repository eine Pipeline auslöst, dann wird die Version der YAML-Datei anhand des Commits bestimmt, der die Pipeline ausgelöst hat. Wenn eine Änderung an einer anderen Repositoryressource die Pipeline auslöst, wird die neueste YAML-Version aus dem Standardbranch des self-Repositorys verwendet.

Wenn ein Update für eines der Repositorys eine Pipeline auslöst, werden abhängig vom auslösenden Repository die folgenden Variablen festgelegt:

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

Für das auslösende Repository wird die ausgecheckte Version des Codes durch den Commit bestimmt, der die Pipeline ausgelöst hat. Für andere Repositorys bestimmt der ref, der in der YAML für diese Repositoryressource definiert ist, die ausgecheckte Standardversion.

Betrachten Sie das folgende Beispiel, bei dem das Repository self die YAML-Datei enthält und die Repositorys A und B zusätzlichen Quellcode enthalten.

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

Die folgende Tabelle zeigt, welche Versionen für jedes Repository von einer Pipeline unter Verwendung der oben genannten YAML-Datei ausgecheckt werden.

Änderung an	Pipeline ausgelöst	YAML-Version	Version von `self`	Version von `A`	Version von `B`
`main` in `self`	Ja	Commit aus `main`, der die Pipeline ausgelöst hat	Commit aus `main`, der die Pipeline ausgelöst hat	neueste aus `main`	neueste aus `release`
`feature` in `self`	Ja	Commit aus `feature`, der die Pipeline ausgelöst hat	Commit aus `feature`, der die Pipeline ausgelöst hat	neueste aus `main`	neueste aus `release`
`main` in `A`	Ja	neueste aus `main`	neueste aus `main`	Commit aus `main`, der die Pipeline ausgelöst hat	neueste aus `release`
`main` in `B`	Ja	neueste aus `main`	neueste aus `main`	neueste aus `main`	Commit aus `main`, der die Pipeline ausgelöst hat
`release` in `B`	Ja	neueste aus `main`	neueste aus `main`	neueste aus `main`	Commit aus `release`, der die Pipeline ausgelöst hat

Sie können die Pipeline auch auslösen, wenn Sie einen Pull Request in einem der Repositorys erstellen oder aktualisieren. Dazu deklarieren Sie die Repositoryressourcen in den YAML-Dateien wie in den obigen Beispielen und konfigurieren eine Branchrichtlinie im Repository (nur Azure Repos).

Details zum Repository

Wenn Sie mehrere Repositorys auschecken, stehen einige Details zum self-Repository als Variablen zur Verfügung. Wenn Sie Trigger für mehrere Repositorys verwenden, enthalten einige dieser Variablen stattdessen Informationen über das auslösende Repository. Details zu allen vom Auftrag genutzten Repositorys sind als Vorlagenkontextobjekt namens resources.repositories verfügbar.

Um zum Beispiel den Verweis für ein Repository zu erhalten, bei dem es sich nicht um self handelt, könnten Sie eine Pipeline wie diese schreiben:

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"

Häufig gestellte Fragen

Warum kann ich kein Repository aus einem anderen Projekt auschecken? Vorher hat dies funktioniert.
Warum werde ich beim ersten Versuch, ein anderes Repository auszuchecken, zur Autorisierung von Ressourcen aufgefordert?

Warum kann ich kein Repository aus einem anderen Projekt auschecken? Vorher hat dies funktioniert.

Azure Pipelines stellt eine Einstellung Auftragsautorisierungsbereich auf aktuelles Projekt beschränken bereit. Diese Einstellung bewirkt, dass die Pipeline nicht auf Ressourcen außerhalb des Projekts zugreifen kann, in dem die Pipeline enthalten ist. Diese Einstellung kann entweder auf Organisations- oder Projektebene festgelegt werden. Wenn diese Einstellung aktiviert ist, kann ein Repository in einem anderen Projekt nur dann ausgecheckt werden, wenn Sie explizit Zugriff gewähren. Weitere Informationen finden Sie unter Auftragsautorisierungsbereich.

Warum werde ich beim ersten Versuch, ein anderes Repository auszuchecken, zur Autorisierung von Ressourcen aufgefordert?

Wenn Sie andere Azure Repos Git-Repositorys als das auschecken, das die Pipeline enthält, werden Sie möglicherweise aufgefordert, den Zugriff auf diese Ressource zu autorisieren, bevor die Pipeline zum ersten Mal ausgeführt wird. Diese Eingabeaufforderungen werden auf der Zusammenfassungsseite der Pipelineausführung angezeigt.

Pipeline benötigt Berechtigung zum Zugriff auf eine Ressource