Eseguire il checkout di più repository nella pipeline

Articolo
05/04/2023

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

Le pipeline spesso si basano su più repository che contengono origine, strumenti, script o altri elementi necessari per compilare il codice. Usando più checkout passaggi nella pipeline, è possibile recuperare ed eseguire il check-out di altri repository oltre a quello usato per archiviare la pipeline YAML.

Specificare più repository

I repository possono essere specificati come risorsa del repository o inline con il checkout passaggio.

Sono supportati i tipi di repository seguenti.

Git Azure Repos (git)

Azure DevOps Server (limitato ai repository nella stessa organizzazione)
Servizi di Azure DevOps

GitHub (github)

Servizi di Azure DevOps

GitHubEnterprise (githubenterprise)

Servizi di Azure DevOps

Bitbucket Cloud (bitbucket)

Servizi di Azure DevOps

Importante

Solo i repository Git di Azure Repos (git) nella stessa organizzazione della pipeline sono supportati per il checkout multi-repository in Azure DevOps Server.

Nota

Azure Pipelines fornisce le impostazioni dell'ambito del processo limite per i repository Git di Azure Repos. Per controllare i repository Git di Azure Repos ospitati in un altro progetto, è necessario configurare l'ambito limite del processo per consentire l'accesso. Per altre informazioni, vedere Limitare l'ambito di autorizzazione del processo.

Sono supportate le combinazioni di checkout passaggi seguenti.

Nessun checkout passaggio

Il comportamento predefinito è come se checkout: self fosse il primo passaggio e il repository corrente viene estratto.

Un singolo checkout: none passaggio

Nessun repository viene sincronizzato o estratto.

Un singolo checkout: self passaggio

Il repository corrente è estratto.

Un singolo checkout passaggio che non self è o none

Il repository designato viene estratto anziché self.

Più checkout passaggi

Ogni repository designato viene estratto in una cartella denominata dopo il repository, a meno che non venga specificato un altro path nel checkout passaggio. Per eseguire il check-out self come uno dei repository, usare checkout: self come uno dei checkout passaggi.

Nota

Quando si esegue il checkout di repository Azure Repos Git diversi da quello contenente la pipeline, potrebbe essere richiesto di autorizzare l'accesso a tale risorsa prima della prima esecuzione della pipeline. Per altre informazioni, vedere Perché viene richiesto di autorizzare le risorse la prima volta che si tenta di controllare un repository diverso? nella sezione Domande frequenti .

Definizione della risorsa del repository

È necessario usare una risorsa del repository se il tipo di repository richiede una connessione al servizio o un altro campo delle risorse estese. I tipi di repository seguenti richiedono una connessione al servizio.

Tipo di repository	Connessione al servizio
Bitbucket Cloud	Bitbucket Cloud
GitHub	GitHub
GitHub Enterprise Server	GitHub Enterprise Server
Repository Git di Azure Repos in un'organizzazione diversa rispetto alla pipeline	Azure Repos/Team Foundation Server

È possibile usare una risorsa del repository anche se il tipo di repository non richiede una connessione al servizio, ad esempio se si dispone di una risorsa del repository già definita per i modelli in un repository diverso.

Nell'esempio seguente, tre repository vengono dichiarati come risorse del repository. Il repository Git Azure Repos in un'altra organizzazione, GitHub e risorse del repository Cloud Bitbucket richiedono connessioni al servizio, specificate come per tali risorse del endpoint repository. Questo esempio include quattro checkout passaggi, che estrae i tre repository dichiarati come risorse del repository insieme al repository corrente self che contiene la pipeline YAML.

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)

Se il self repository è denominato CurrentRepo, il script comando produce l'output seguente: CurrentRepo MyAzureReposGitRepo MyBitbucketRepo MyGitHubRepo. In questo esempio, i nomi dei repository (come specificato dalla name proprietà nella risorsa repository) vengono usati per le cartelle, perché non path viene specificato nel passaggio di estrazione. Per altre informazioni sui nomi e le posizioni delle cartelle del repository, vedere la sezione Percorso di estrazione seguente.

Estrazione della sintassi inline

Se il repository non richiede una connessione al servizio, è possibile dichiararlo inline con il checkout passaggio.

Nota

Solo i repository Git Di Azure Repos nella stessa organizzazione possono usare la sintassi inline. I repository Git di Azure Repos in un'organizzazione diversa e altri tipi di repository supportati richiedono una connessione al servizio e devono essere dichiarati come risorsa del repository.

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

Nota

Nell'esempio precedente viene specificato il self repository di estrazione per estrarre l'origine del repository associato alla pipeline.

Se si usa il repository Git Azure Repos predefinito (con lo stesso nome del progetto), usare il formato - checkout: git://MyProject/MyRepo.

Percorso di estrazione

A meno che non path sia specificato nel passaggio, il checkout codice sorgente viene inserito in una directory predefinita. Questa directory è diversa a seconda che si estraa un singolo repository o più repository.

Repository singolo: se si ha un singolo checkout passaggio nel processo o non si dispone di un passaggio di estrazione equivalente a checkout: self, il codice sorgente viene estratto in una directory denominata denominata s sottocartella di (Agent.BuildDirectory). Se (Agent.BuildDirectory) è C:\agent\_work\1, il codice viene estratto su C:\agent\_work\1\s.
Più repository: se sono presenti più checkout passaggi nel processo, il codice sorgente viene estratto nelle directory denominate dopo i repository come sottocartella di s in (Agent.BuildDirectory). Se (Agent.BuildDirectory) è C:\agent\_work\1 e i repository sono denominati tools e code, il codice viene estratto in C:\agent\_work\1\s\tools e C:\agent\_work\1\s\code.

Nota

Se nel passaggio non viene specificato alcun path valore checkout , il nome del repository viene usato per la cartella, non il repository valore usato per fare riferimento al repository nel checkout passaggio.

Se per un passaggio viene specificato un path checkout oggetto , tale percorso viene usato rispetto a (Agent.BuildDirectory).

Nota

Se si usano percorsi predefiniti, l'aggiunta di un secondo passaggio del repository checkout modifica il percorso predefinito del codice per il primo repository. Ad esempio, il codice per un repository denominato tools viene estratto C:\agent\_work\1\s quando tools è l'unico repository, ma se viene aggiunto un secondo repository, tools verrà estratto in C:\agent\_work\1\s\tools. Se sono presenti passaggi che dipendono dal codice sorgente presente nel percorso originale, questi passaggi devono essere aggiornati.

Estrazione di un riferimento specifico

Il ramo predefinito viene estratto a meno che non si designi un riferimento specifico.

Se si usa la sintassi inline, designare il riferimento aggiungendo @<ref>. Ad esempio:

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

Quando si usa una risorsa del repository, specificare il riferimento usando la ref proprietà . Nell'esempio seguente viene estratto il features/tools/ ramo del repository designato.

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

steps:
- checkout: MyGitHubRepo

Nell'esempio seguente vengono usati tag per controllare il commit a cui fa MyTagriferimento .

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

steps:
- checkout: MyGitHubRepo

Trigger

È possibile attivare una pipeline quando viene eseguito il push di un aggiornamento nel self repository o in uno qualsiasi dei repository dichiarati come risorse. Ciò è utile, ad esempio, negli scenari seguenti:

Si utilizza uno strumento o una libreria da un repository diverso. Si vogliono eseguire test per l'applicazione ogni volta che viene aggiornato lo strumento o la libreria.
Il file YAML viene mantenuto in un repository separato dal codice dell'applicazione. Si vuole attivare la pipeline ogni volta che viene eseguito il push di un aggiornamento nel repository dell'applicazione.

Importante

I trigger di risorse del repository funzionano solo per i repository Git Di Azure Repos nella stessa organizzazione e quando il self tipo di repository è Azure Repos Git. Non funzionano per le risorse del repository GitHub o Bitbucket.

batch non è supportato nei trigger di risorse del repository.

Se non si specifica una trigger sezione in una risorsa del repository, la pipeline non verrà attivata dalle modifiche apportate a tale repository. Se si specifica una trigger sezione, il comportamento per l'attivazione è simile al funzionamento dei trigger CI per il repository self.

Se si specifica una trigger sezione per più risorse del repository, verrà avviata una nuova esecuzione.

Quando viene attivata una pipeline, Azure Pipelines deve determinare la versione del file YAML da usare e una versione per ogni repository che deve essere estratto. Se una modifica al self repository attiva una pipeline, viene usato il commit che ha attivato la pipeline per determinare la versione del file YAML. Se una modifica a qualsiasi altra risorsa del repository attiva la pipeline, viene usata la versione più recente di YAML dal ramo predefinito del self repository.

Quando un aggiornamento a uno dei repository attiva una pipeline, le variabili seguenti vengono impostate in base all'attivazione del repository:

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

Per il repository di attivazione, il commit che ha attivato la pipeline determina la versione del codice estratto. Per altri repository, l'oggetto ref definito in YAML per tale risorsa del repository determina la versione predefinita estratta.

Si consideri l'esempio seguente, in cui il self repository contiene il file YAML e i repository A e B contiene codice sorgente aggiuntivo.

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

La tabella seguente illustra le versioni estratte per ogni repository da una pipeline usando il file YAML precedente.

Modifica apportata a	Pipeline attivata	Versione di YAML	Versione di `self`	Versione di `A`	Versione di `B`
`main` in `self`	Sì	commit da `main` che ha attivato la pipeline	commit da `main` che ha attivato la pipeline	più recente da `main`	più recente da `release`
`feature` in `self`	Sì	commit da `feature` che ha attivato la pipeline	commit da `feature` che ha attivato la pipeline	più recente da `main`	più recente da `release`
`main` in `A`	Sì	più recente da `main`	più recente da `main`	commit da `main` che ha attivato la pipeline	più recente da `release`
`main` in `B`	Sì	più recente da `main`	più recente da `main`	più recente da `main`	commit da `main` che ha attivato la pipeline
`release` in `B`	Sì	più recente da `main`	più recente da `main`	più recente da `main`	commit da `release` che ha attivato la pipeline

È anche possibile attivare la pipeline quando si crea o si aggiorna una richiesta pull in uno qualsiasi dei repository. A tale scopo, dichiarare le risorse del repository nei file YAML come negli esempi precedenti e configurare un criterio di ramo nel repository (solo Azure Repos).

Dettagli del repository

Quando si estrae più repository, alcuni dettagli sul self repository sono disponibili come variabili. Quando si usano trigger multi-repository, alcune di queste variabili includono invece informazioni sul repository di attivazione. I dettagli su tutti i repository utilizzati dal processo sono disponibili come oggetto contesto modello denominato resources.repositories.

Ad esempio, per ottenere il riferimento di un repository nonself , è possibile scrivere una pipeline simile alla seguente:

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"

Domande frequenti

Perché non è possibile eseguire il check-out di un repository da un altro progetto? In precedenza funzionava.
Perché viene richiesto di autorizzare le risorse la prima volta che si tenta di eseguire il check-out di un repository diverso?

Perché non è possibile eseguire il check-out di un repository da un altro progetto? In precedenza funzionava.

Azure Pipelines fornisce un ambito di abilitare Limita processo all'impostazione di progetto corrente, che, se abilitata, non consente alla pipeline di accedere alle risorse all'esterno del progetto che contiene la pipeline. Questa impostazione può essere regolata a livello di organizzazione o progetto. Se questa impostazione è abilitata, non sarà possibile eseguire il checkout di un repository in un altro progetto, a meno che non si conceda in modo esplicito l'accesso. Per altre informazioni, vedere Ambito di autorizzazione processo.

Perché viene richiesto di autorizzare le risorse la prima volta che si tenta di eseguire il check-out di un repository diverso?

Quando si esegue il checkout di repository Azure Repos Git diversi da quello contenente la pipeline, potrebbe essere richiesto di autorizzare l'accesso a tale risorsa prima della prima esecuzione della pipeline. Queste richieste vengono visualizzate nella pagina di riepilogo dell'esecuzione della pipeline.

Questa pipeline richiede l'autorizzazione per accedere a una risorsa