Auschecken mehrerer Repositorys in Ihrer Pipeline
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://MyRepo/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 (wascheckout: self
entspricht), wird Ihr Quellcode in ein Verzeichnis namenss
ausgecheckt, das sich in einem Unterordner von(Agent.BuildDirectory)
befindet. Wenn(Agent.BuildDirectory)
alsC:\agent\_work\1
angegeben ist, wird Ihr Code inC:\agent\_work\1\s
ausgecheckt.Mehrere Repositorys: Wenn Sie mehrere
checkout
-Schritte in Ihrem Auftrag verwenden, wird Ihr Quellcode in Verzeichnisse ausgecheckt, die nach den Repositorys als Unterordner vons
in(Agent.BuildDirectory)
benannt sind. Wenn(Agent.BuildDirectory)
alsC:\agent\_work\1
angegeben ist und die Namen Ihrer Repositorystools
undcode
lauten, wird Ihr Code inC:\agent\_work\1\s\tools
undC:\agent\_work\1\s\code
ausgecheckt.Hinweis
Wenn im
checkout
-Schritt keinpath
angegeben wird, wird anstelle desrepository
-Werts, der imcheckout
-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.
Wählen Sie Anzeigen oder Ressourcen autorisieren aus, und befolgen Sie die Anweisungen zum Autorisieren der Ressourcen.
Weitere Informationen finden Sie unter Problembehandlung bei der Autorisierung für eine YAML-Pipeline.