Kolla in flera lagringsplatser i pipelinen

Artikel
02/28/2024

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

Pipelines förlitar sig ofta på flera lagringsplatser som innehåller källan, verktyg, skript eller andra objekt som du behöver för att kompilera koden. Genom att använda flera checkout steg i pipelinen kan du hämta och checka ut andra lagringsplatser utöver den du använder för att lagra YAML-pipelinen.

Ange flera lagringsplatser

Lagringsplatser kan anges som en lagringsplatsresurs eller infogas checkout i steget.

Följande lagringsplatstyper stöds.

Azure Repos Git (git)

Azure DevOps Server (begränsat till lagringsplatser i samma organisation)
Azure DevOps Services

GitHub (github)

Azure DevOps Services

GitHubEnterprise (githubenterprise)

Azure DevOps Services

Bitbucket Cloud (bitbucket)

Azure DevOps Services

Viktigt!

Endast Azure Repos Git-lagringsplatser (git) i samma organisation som pipelinen stöds för utcheckning av flera lagringsplatser i Azure DevOps Server.

Kommentar

Azure Pipelines tillhandahåller begränsa jobbomfattningsinställningar för Azure Repos Git-lagringsplatser. Om du vill kolla in Azure Repos Git-lagringsplatser som finns i ett annat projekt måste begränsa jobbomfånget konfigureras för att tillåta åtkomst. Mer information finns i Begränsa omfånget för jobbauktorisering.

Följande kombinationer av checkout steg stöds.

Inga checkout steg

Standardbeteendet är som om checkout: self det var det första steget och den aktuella lagringsplatsen är utcheckad.

Ett enda checkout: none steg

Inga lagringsplatser synkroniseras eller checkas ut.

Ett enda checkout: self steg

Den aktuella lagringsplatsen är utcheckad.

Ett enda checkout steg som inte self är eller none

Den avsedda lagringsplatsen är utcheckad i stället för self.

Flera checkout steg

Varje utsedd lagringsplats checkas ut till en mapp med namnet efter lagringsplatsen, såvida inte en annan path anges i checkout steget. Om du vill checka ut self som en av lagringsplatserna använder du checkout: self som ett av checkout stegen.

Kommentar

När du checkar ut andra Git-lagringsplatser för Azure Repos än den som innehåller pipelinen kan du uppmanas att auktorisera åtkomst till resursen innan pipelinen körs för första gången. Mer information finns i Varför uppmanas jag att auktorisera resurser första gången jag försöker kolla in en annan lagringsplats? i avsnittet Vanliga frågor och svar .

Resursdefinition för lagringsplats

Du måste använda en lagringsplatsresurs om din lagringsplatstyp kräver en tjänstanslutning eller ett annat fält för utökade resurser. Följande lagringsplatstyper kräver en tjänstanslutning.

Lagringsplatstyp	Tjänstanslutning
Bitbucket Cloud	Bitbucket Cloud
GitHub	GitHub
GitHub Enterprise Server	GitHub Enterprise Server
Azure Repos Git-lagringsplatser i en annan organisation än din pipeline	Azure Repos/Team Foundation Server

Du kan använda en lagringsplatsresurs även om din lagringsplatstyp inte kräver någon tjänstanslutning, till exempel om du redan har definierat en lagringsplatsresurs för mallar på en annan lagringsplats.

I följande exempel deklareras tre lagringsplatser som lagringsplatsresurser. Azure Repos Git-lagringsplatsen i en annan organisation, GitHub och Bitbucket Cloud-lagringsplatsen kräver tjänstanslutningar, som anges som endpoint för dessa lagringsplatsresurser. Det här exemplet innehåller fyra checkout steg som checkar ut de tre lagringsplatser som deklarerats som lagringsplatsresurser tillsammans med den aktuella self lagringsplatsen som innehåller yaml-pipelinen.

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)

Om lagringsplatsen self heter CurrentReposcript genererar kommandot följande utdata: CurrentRepo MyAzureReposGitRepo MyBitbucketRepo MyGitHubRepo. I det här exemplet används namnen på lagringsplatserna (som anges av name egenskapen i lagringsplatsens resurs) för mapparna, eftersom inget path anges i utcheckningssteget. Mer information om lagringsplatsens mappnamn och platser finns i följande avsnitt om sökväg till utcheckning.

Infogad syntaxutcheckning

Om lagringsplatsen inte kräver någon tjänstanslutning kan du deklarera den i din checkout steg.

Kommentar

Endast Azure Repos Git-lagringsplatser i samma organisation kan använda den infogade syntaxen. Azure Repos Git-lagringsplatser i en annan organisation och andra typer av lagringsplatser som stöds kräver en tjänstanslutning och måste deklareras som en lagringsplatsresurs.

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

Kommentar

I föregående exempel self anges utcheckningslagringsplatsen för att kunna checka ut källan till den lagringsplats som är associerad med pipelinen.

Om du använder standardlagringsplatsen för Azure Repos Git (som har samma namn som projektet) använder du formatet - checkout: git://MyProject/MyRepo.

Sökväg till utcheckning

Om inte en path anges i steget placeras källkoden checkout i en standardkatalog. Den här katalogen skiljer sig beroende på om du checkar ut en enskild lagringsplats eller flera lagringsplatser.

Enskild lagringsplats: Om du har ett enda checkout steg i jobbet, eller om du inte har något utcheckningssteg som motsvarar , checkas källkoden ut till en katalog som heter s som en undermapp (Agent.BuildDirectory)till checkout: self. Om (Agent.BuildDirectory) är C:\agent\_work\1checkas koden ut till C:\agent\_work\1\s.
Flera lagringsplatser: Om du har flera checkout steg i jobbet checkas källkoden ut till kataloger med namnet efter lagringsplatserna som en undermapp s i i (Agent.BuildDirectory). Om (Agent.BuildDirectory) är C:\agent\_work\1 och dina lagringsplatser namnges tools och codecheckas koden ut till C:\agent\_work\1\s\tools och C:\agent\_work\1\s\code.

Kommentar

Om inget path anges i checkout steget används namnet på lagringsplatsen för mappen, inte det repository värde som används för att referera till lagringsplatsen i checkout steget.

Om en path anges för ett checkout steg används den sökvägen i förhållande till (Agent.BuildDirectory).

Kommentar

Om du använder standardsökvägar ändrar du standardsökvägen för koden för den första lagringsplatsen genom att lägga till ett andra lagringsplatssteg checkout . Koden för en lagringsplats med namnet tools skulle till exempel checkas ut till C:\agent\_work\1\s när tools är den enda lagringsplatsen, men om en andra lagringsplats läggs till tools checkas den ut till C:\agent\_work\1\s\tools. Om du har några steg som är beroende av att källkoden finns på den ursprungliga platsen måste dessa steg uppdateras.

Checka ut en specifik referens

Standardgrenen är utcheckad om du inte anger en specifik referens.

Om du använder infogad syntax anger du referensen genom att lägga till @<ref>. Till exempel:

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

När du använder en lagringsplatsresurs anger du referensen med egenskapen ref . I följande exempel checkas grenen features/tools/ av den avsedda lagringsplatsen ut.

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

steps:
- checkout: MyGitHubRepo

I följande exempel används taggar för att kolla in incheckningen som refereras av MyTag.

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

steps:
- checkout: MyGitHubRepo

Utlösare

Du kan utlösa en pipeline när en uppdatering skickas till self lagringsplatsen eller till någon av de lagringsplatser som deklareras som resurser. Detta är till exempel användbart i följande scenarier:

Du använder ett verktyg eller ett bibliotek från en annan lagringsplats. Du vill köra tester för ditt program när verktyget eller biblioteket uppdateras.
Du behåller YAML-filen på en separat lagringsplats från programkoden. Du vill utlösa pipelinen varje gång en uppdatering skickas till programlagringsplatsen.

Viktigt!

Lagringsplatsens resursutlösare fungerar endast för Azure Repos Git-lagringsplatser i samma organisation och när self lagringsplatsens typ är Azure Repos Git. De fungerar inte för GitHub- eller Bitbucket-lagringsplatsens resurser.

batch stöds inte i lagringsplatsens resursutlösare.

Om du inte anger ett trigger avsnitt i en lagringsplatsresurs utlöses inte pipelinen av ändringar i lagringsplatsen. Om du anger ett trigger avsnitt liknar beteendet för utlösande hur CI-utlösare fungerar för självlagringsplatsen.

Om du anger ett trigger avsnitt för flera lagringsplatsresurser startar en ändring av någon av dem en ny körning.

När en pipeline utlöses måste Azure Pipelines fastställa vilken version av YAML-filen som ska användas och en version för varje lagringsplats som ska checkas ut. Om en ändring av self lagringsplatsen utlöser en pipeline används incheckningen som utlöste pipelinen för att fastställa versionen av YAML-filen. Om en ändring av någon annan lagringsplatsresurs utlöser pipelinen används den senaste versionen av YAML från standardgrenen för self lagringsplatsen.

När en uppdatering till en av lagringsplatserna utlöser en pipeline anges följande variabler baserat på utlösande lagringsplats:

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

För den utlösande lagringsplatsen avgör incheckningen som utlöste pipelinen vilken version av koden som är utcheckad. För andra lagringsplatser avgör den ref definierade i YAML för den lagringsresursen den standardversion som är utcheckad.

Tänk dig följande exempel, där self lagringsplatsen innehåller YAML-filen och lagringsplatserna A och B innehåller ytterligare källkod.

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

I följande tabell visas vilka versioner som checkas ut för varje lagringsplats av en pipeline med hjälp av YAML-filen ovan.

Ändring som gjorts i	Pipeline utlöses	Version av YAML	Version av `self`	Version av `A`	Version av `B`
`main` in `self`	Ja	commit från `main` som utlöste pipelinen	commit från `main` som utlöste pipelinen	senaste från `main`	senaste från `release`
`feature` in `self`	Ja	commit från `feature` som utlöste pipelinen	commit från `feature` som utlöste pipelinen	senaste från `main`	senaste från `release`
`main` in `A`	Ja	senaste från `main`	senaste från `main`	commit från `main` som utlöste pipelinen	senaste från `release`
`main` in `B`	Ja	senaste från `main`	senaste från `main`	senaste från `main`	commit från `main` som utlöste pipelinen
`release` in `B`	Ja	senaste från `main`	senaste från `main`	senaste från `main`	commit från `release` som utlöste pipelinen

Du kan också utlösa pipelinen när du skapar eller uppdaterar en pull-begäran på någon av lagringsplatserna. För att göra detta deklarerar du lagringsplatsens resurser i YAML-filerna som i exemplen ovan och konfigurerar en grenprincip på lagringsplatsen (endast Azure Repos).

Information om lagringsplats

När du checkar ut flera lagringsplatser är viss information om lagringsplatsen self tillgänglig som variabler. När du använder utlösare för flera lagringsplatser har vissa av dessa variabler information om den utlösande lagringsplatsen i stället. Information om alla lagringsplatser som används av jobbet är tillgängliga som ett mallkontextobjekt med namnet resources.repositories.

Om du till exempel vill hämta referensen för en icke-lagringsplatsself kan du skriva en pipeline så här:

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"

Vanliga frågor

Varför kan jag inte checka ut en lagringsplats från ett annat projekt? Det fungerade tidigare.
Varför uppmanas jag att auktorisera resurser första gången jag försöker checka ut en annan lagringsplats?

Varför kan jag inte checka ut en lagringsplats från ett annat projekt? Det fungerade tidigare.

Azure Pipelines tillhandahåller en inställning för att Begränsa jobbets auktoriseringsområde till aktuellt projekt, som när den är aktiverad inte tillåter pipelinen att komma åt resurser utanför projektet som innehåller pipelinen. Den här inställningen kan anges på organisations- eller projektnivå. Om den här inställningen är aktiverad kan du inte checka ut en lagringsplats i ett annat projekt om du inte uttryckligen beviljar åtkomst. Mer information finns i Auktoriseringsområde för jobb.

Varför uppmanas jag att auktorisera resurser första gången jag försöker checka ut en annan lagringsplats?

När du checkar ut andra Git-lagringsplatser för Azure Repos än den som innehåller pipelinen kan du uppmanas att auktorisera åtkomst till resursen innan pipelinen körs för första gången. Dessa uppmaningar visas på sammanfattningssidan för pipeline-körningen.

Den här pipelinen behöver behörighet att komma åt en resurs