Meerdere opslagplaatsen in uw pijplijn uitchecken

Artikel
02/28/2024

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

Pijplijnen zijn vaak afhankelijk van meerdere opslagplaatsen die bron, hulpprogramma's, scripts of andere items bevatten die u nodig hebt om uw code te bouwen. Door meerdere checkout stappen in uw pijplijn te gebruiken, kunt u andere opslagplaatsen ophalen en uitchecken, naast de opslagplaats die u gebruikt om uw YAML-pijplijn op te slaan.

Meerdere opslagplaatsen opgeven

Opslagplaatsen kunnen worden opgegeven als opslagplaatsresource of inline met de checkout stap.

De volgende typen opslagplaatsen worden ondersteund.

Git voor Azure-opslagplaatsen (git)

Azure DevOps Server (beperkt tot opslagplaatsen in dezelfde organisatie)
Azure DevOps Services

GitHub (github)

Azure DevOps Services

GitHubEnterprise (githubenterprise)

Azure DevOps Services

Bitbucket Cloud (bitbucket)

Azure DevOps Services

Belangrijk

Alleen Git-opslagplaatsen () voor Azure-opslagplaatsen ingit dezelfde organisatie als de pijplijn worden ondersteund voor het uitchecken van meerdere opslagplaatsen in Azure DevOps Server.

Notitie

Azure Pipelines biedt instellingen voor taakbereik beperken voor Git-opslagplaatsen van Azure-opslagplaatsen. Als u Git-opslagplaatsen van Azure-opslagplaatsen wilt uitchecken die worden gehost in een ander project, moet het taakbereik beperken zijn geconfigureerd om toegang toe te staan. Zie Het bereik voor taakautorisatie beperken voor meer informatie.

De volgende combinaties van checkout stappen worden ondersteund.

Geen checkout stappen

Het standaardgedrag is alsof dit checkout: self de eerste stap is en de huidige opslagplaats is uitgecheckt.

Eén checkout: none stap

Er worden geen opslagplaatsen gesynchroniseerd of uitgecheckt.

Eén checkout: self stap

De huidige opslagplaats is uitgecheckt.

checkout Eén stap die niet self ofnone

De aangewezen opslagplaats is uitgecheckt in plaats van self.

Meerdere checkout stappen

Elke aangewezen opslagplaats wordt uitgecheckt naar een map met de naam van de opslagplaats, tenzij er een andere path is opgegeven in de checkout stap. Als u wilt uitchecken self als een van de opslagplaatsen, gebruikt checkout: self u deze als een van de checkout stappen.

Notitie

Wanneer u andere Git-opslagplaatsen van Azure-opslagplaatsen dan de opslagplaats met de pijplijn controleert, wordt u mogelijk gevraagd om toegang tot die resource te verlenen voordat de pijplijn voor de eerste keer wordt uitgevoerd. Zie Waarom wordt ik gevraagd om resources de eerste keer dat ik een andere opslagplaats probeer te bekijken, te autoriseren? in de sectie Veelgestelde vragen voor meer informatie.

Resourcedefinitie van opslagplaats

U moet een opslagplaatsresource gebruiken als voor uw type opslagplaats een serviceverbinding of een ander veld met uitgebreide resources is vereist. Voor de volgende typen opslagplaatsen is een serviceverbinding vereist.

Type opslagplaats	Serviceverbinding
Bitbucket Cloud	Bitbucket Cloud
GitHub	GitHub
GitHub Enterprise Server	GitHub Enterprise Server
Git-opslagplaatsen van Azure-opslagplaatsen in een andere organisatie dan uw pijplijn	Azure-opslagplaatsen/Team Foundation Server

U kunt een opslagplaatsresource gebruiken, zelfs als uw opslagplaatstype geen serviceverbinding vereist, bijvoorbeeld als u een opslagplaatsresource hebt gedefinieerd die al is gedefinieerd voor sjablonen in een andere opslagplaats.

In het volgende voorbeeld worden drie opslagplaatsen gedeclareerd als opslagplaatsresources. Voor de Git-opslagplaats voor Azure-opslagplaatsen in een andere organisatie, GitHub en Bitbucket Cloud-opslagplaatsresources zijn serviceverbindingen vereist. Deze worden opgegeven als de endpoint opslagplaatsresources. Dit voorbeeld heeft vier checkout stappen, waarmee de drie opslagplaatsen worden uitgecheckt die zijn gedeclareerd als opslagplaatsresources, samen met de huidige self opslagplaats die de YAML-pijplijn bevat.

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)

Als de self opslagplaats de naam CurrentRepoheeft, produceert de script opdracht de volgende uitvoer: CurrentRepo MyAzureReposGitRepo MyBitbucketRepo MyGitHubRepo In dit voorbeeld worden de namen van de opslagplaatsen (zoals opgegeven door de name eigenschap in de opslagplaatsresource) gebruikt voor de mappen, omdat er geen path is opgegeven in de uitcheckstap. Zie de volgende sectie voor uitcheckpaden voor meer informatie over de mapnamen en locaties van de opslagplaats.

Inline syntaxis uitchecken

Als voor uw opslagplaats geen serviceverbinding is vereist, kunt u deze inline declareren met uw checkout stap.

Notitie

Alleen Git-opslagplaatsen van Azure-opslagplaatsen in dezelfde organisatie kunnen de inlinesyntaxis gebruiken. Git-opslagplaatsen van Azure-opslagplaatsen in een andere organisatie en andere ondersteunde opslagplaatstypen vereisen een serviceverbinding en moeten worden gedeclareerd als opslagplaatsresource.

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

Notitie

In het vorige voorbeeld wordt de self opslagplaats voor het uitchecken opgegeven om de bron van de opslagplaats te bekijken die is gekoppeld aan de pijplijn.

Als u de standaardOpslagplaats voor Azure-opslagplaatsen gebruikt (die dezelfde naam heeft als het project), gebruikt u de indeling - checkout: git://MyProject/MyRepo.

Pad naar uitchecken

Tenzij er een path is opgegeven in de checkout stap, wordt de broncode in een standaardmap geplaatst. Deze map verschilt, afhankelijk van of u één opslagplaats of meerdere opslagplaatsen uitcheckt.

Eén opslagplaats: Als u één checkout stap in uw taak hebt of als u geen uitcheckstap hebt die gelijk is aan checkout: self, wordt uw broncode uitgecheckt naar een map die wordt aangeroepen s als een submap van (Agent.BuildDirectory). Als (Agent.BuildDirectory) dat het is C:\agent\_work\1, wordt uw code uitgecheckt naar C:\agent\_work\1\s.
Meerdere opslagplaatsen: als u meerdere checkout stappen in uw taak hebt, wordt uw broncode uitgecheckt naar mappen met de naam van de opslagplaatsen als submap van s in (Agent.BuildDirectory). Als (Agent.BuildDirectory) dat het is C:\agent\_work\1 en uw opslagplaatsen een naam tools hebben en codeuw code wordt uitgecheckt naar C:\agent\_work\1\s\tools en C:\agent\_work\1\s\code.

Notitie

Als er geen is path opgegeven in de checkout stap, wordt de naam van de opslagplaats gebruikt voor de map, niet de repository waarde die wordt gebruikt om te verwijzen naar de opslagplaats in de checkout stap.

Als er een path is opgegeven voor een checkout stap, wordt dat pad gebruikt ten opzichte van (Agent.BuildDirectory).

Notitie

Als u standaardpaden gebruikt, verandert het toevoegen van een tweede opslagplaatsstap checkout het standaardpad van de code voor de eerste opslagplaats. De code voor een benoemde tools opslagplaats wordt bijvoorbeeld uitgecheckt naar C:\agent\_work\1\s wanneer tools de enige opslagplaats is, maar als er een tweede opslagplaats wordt toegevoegd, tools wordt deze uitgecheckt naar C:\agent\_work\1\s\tools. Als u stappen hebt die afhankelijk zijn van de broncode die zich op de oorspronkelijke locatie bevindt, moeten deze stappen worden bijgewerkt.

Een specifieke ref uitchecken

De standaardvertakking wordt uitgecheckt, tenzij u een specifieke verwijzing aanwijst.

Als u inlinesyntaxis gebruikt, wijst u de verwijzing aan door toe te @<ref>voegen. Voorbeeld:

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

Wanneer u een opslagplaatsresource gebruikt, geeft u de verwijzing op met behulp van de ref eigenschap. In het volgende voorbeeld wordt de features/tools/ vertakking van de aangewezen opslagplaats uitgecheckt.

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

steps:
- checkout: MyGitHubRepo

In het volgende voorbeeld worden tags gebruikt om de doorvoer te bekijken waarnaar wordt verwezen.MyTag

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

steps:
- checkout: MyGitHubRepo

Triggers

U kunt een pijplijn activeren wanneer een update naar de self opslagplaats wordt gepusht of naar een van de opslagplaatsen die zijn gedeclareerd als resources. Dit is bijvoorbeeld handig in de volgende scenario's:

U gebruikt een hulpprogramma of bibliotheek uit een andere opslagplaats. U wilt tests voor uw toepassing uitvoeren wanneer het hulpprogramma of de bibliotheek wordt bijgewerkt.
U houdt uw YAML-bestand in een afzonderlijke opslagplaats van de toepassingscode. U wilt de pijplijn telkens activeren wanneer een update naar de toepassingsopslagplaats wordt gepusht.

Belangrijk

Resourcetriggers voor opslagplaatsen werken alleen voor Git-opslagplaatsen in Azure-opslagplaatsen in dezelfde organisatie en wanneer het self type opslagplaats Git azure-opslagplaatsen is. Ze werken niet voor GitHub- of Bitbucket-opslagplaatsresources.

batch wordt niet ondersteund in resourcetriggers voor opslagplaatsen.

Als u geen sectie in een opslagplaatsresource opgeeft trigger , wordt de pijplijn niet geactiveerd door wijzigingen in die opslagplaats. Als u een trigger sectie opgeeft, is het gedrag voor triggering vergelijkbaar met de werking van CI-triggers voor de zelfopslagplaats.

Als u een trigger sectie opgeeft voor meerdere opslagplaatsresources, wordt een nieuwe uitvoering gestart door een wijziging in een van deze resources.

Wanneer een pijplijn wordt geactiveerd, moet Azure Pipelines bepalen welke versie van het YAML-bestand moet worden gebruikt en een versie voor elke opslagplaats die moet worden uitgecheckt. Als een wijziging in de self opslagplaats een pijplijn activeert, wordt de doorvoer die de pijplijn heeft geactiveerd, gebruikt om de versie van het YAML-bestand te bepalen. Als een wijziging in een andere opslagplaatsresource de pijplijn activeert, wordt de nieuwste versie van YAML uit de standaardbranch van self de opslagplaats gebruikt.

Wanneer een update naar een van de opslagplaatsen een pijplijn activeert, worden de volgende variabelen ingesteld op basis van het activeren van de opslagplaats:

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

Voor de triggerende opslagplaats bepaalt de doorvoering die de pijplijn heeft geactiveerd de versie van de code die is uitgecheckt. Voor andere opslagplaatsen bepaalt de ref gedefinieerde in de YAML voor die opslagplaatsresource de standaardversie die is uitgecheckt.

Bekijk het volgende voorbeeld, waarbij de self opslagplaats het YAML-bestand en de opslagplaatsen A bevat en B aanvullende broncode bevat.

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

In de volgende tabel ziet u welke versies voor elke opslagplaats door een pijplijn worden uitgecheckt met behulp van het bovenstaande YAML-bestand.

Wijziging aangebracht in	Pijplijn geactiveerd	Versie van YAML	Versie van `self`	Versie van `A`	Versie van `B`
`main` in `self`	Ja	doorvoeren vanuit `main` die geactiveerde pijplijn	doorvoeren vanuit `main` die geactiveerde pijplijn	nieuwste van `main`	nieuwste van `release`
`feature` in `self`	Ja	doorvoeren vanuit `feature` die geactiveerde pijplijn	doorvoeren vanuit `feature` die geactiveerde pijplijn	nieuwste van `main`	nieuwste van `release`
`main` in `A`	Ja	nieuwste van `main`	nieuwste van `main`	doorvoeren vanuit `main` die geactiveerde pijplijn	nieuwste van `release`
`main` in `B`	Ja	nieuwste van `main`	nieuwste van `main`	nieuwste van `main`	doorvoeren vanuit `main` die geactiveerde pijplijn
`release` in `B`	Ja	nieuwste van `main`	nieuwste van `main`	nieuwste van `main`	doorvoeren vanuit `release` die geactiveerde pijplijn

U kunt de pijplijn ook activeren wanneer u een pull-aanvraag maakt of bijwerkt in een van de opslagplaatsen. Hiervoor declareert u de opslagplaatsresources in de YAML-bestanden zoals in de bovenstaande voorbeelden en configureert u een vertakkingsbeleid in de opslagplaats (alleen Azure-opslagplaatsen).

Gegevens van opslagplaats

Wanneer u meerdere opslagplaatsen uitcheckt, zijn enkele details over de self opslagplaats beschikbaar als variabelen. Wanneer u triggers voor meerdere opslagplaatsen gebruikt, bevatten sommige van deze variabelen in plaats daarvan informatie over de triggerende opslagplaats. Details over alle opslagplaatsen die door de taak worden gebruikt, zijn beschikbaar als een sjablooncontextobject met de naam resources.repositories.

Als u bijvoorbeeld de ref van een niet-opslagplaatsself wilt ophalen, kunt u een pijplijn als volgt schrijven:

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"

Veelgestelde vragen

Waarom kan ik geen opslagplaats uit een ander project uitchecken? Vroeger werkte het wel.
Waarom wordt mij gevraagd om resources de eerste keer te autoriseren wanneer ik een andere opslagplaats probeer te uitchecken?

Waarom kan ik geen opslagplaats uit een ander project uitchecken? Vroeger werkte het wel.

Azure Pipelines biedt een instelling Taakautorisatiebereik beperken voor het huidige project, die, indien ingeschakeld, de pijplijn geen toegang geeft tot resources buiten het project dat de pijplijn bevat. Deze instelling kan worden ingesteld op organisatie- of projectniveau. Als deze instelling is ingeschakeld, kunt u een opslagplaats in een ander project niet uitchecken, tenzij u expliciet toegang toekent. Zie Taakautorisatiebereik voor meer informatie.

Waarom wordt mij gevraagd om resources de eerste keer te autoriseren wanneer ik een andere opslagplaats probeer te uitchecken?

Wanneer u andere Git-opslagplaatsen van Azure-opslagplaatsen dan de opslagplaats met de pijplijn controleert, wordt u mogelijk gevraagd om toegang tot die resource te verlenen voordat de pijplijn voor de eerste keer wordt uitgevoerd. Deze prompts worden weergegeven op de overzichtspagina van de pijplijnuitvoering.

Deze pijplijn heeft toestemming nodig om toegang te krijgen tot een resource