Opzioni della pipeline per i repository Git

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Durante la modifica di una pipeline che usa un repository Git, in un progetto Azure DevOps, GitHub, GitHub Enterprise Server, Bitbucket Cloud o un altro repository Git, sono disponibili le opzioni seguenti.

Funzionalità	Azure Pipelines	Azure DevOps Server 2019 e versioni successive	TFS 2018
Ramo	Sì	Sì	Sì
Pulire	Sì	Sì	Sì
Contrassegna o etichetta le origini	Progetto; Solo classico	Progetto team	Progetto team
Stato della compilazione del report	Sì	Sì	Sì
Vedere i moduli secondari	Sì	Sì	Sì
Estrai file da LFS	Sì	Sì	Sì
Clonare un secondo repository	Sì	Sì	Sì
Non sincronizzare le origini	Sì	Sì	Sì
Recupero superficiale	Sì	Sì	Sì

Nota

Fare clic su Impostazioni avanzate nell'attività Recupera origini per visualizzare alcune delle opzioni precedenti.

Ramo

Si tratta del ramo che si desidera essere l'impostazione predefinita quando si accoda manualmente questa compilazione. Se si imposta un trigger pianificato per la compilazione, si tratta del ramo da cui la compilazione otterrà le origini più recenti. Il ramo predefinito non ha alcun effetto quando la compilazione viene attivata tramite l'integrazione continua (CI). In genere si imposta questa impostazione come il ramo predefinito del repository , ad esempio "master".

Pulire il repository locale nell'agente

È possibile eseguire diverse forme di pulizia della directory di lavoro dell'agente self-hosted prima dell'esecuzione di una compilazione.

In generale, per prestazioni più veloci degli agenti self-hosted, non pulire il repository. In questo caso, per ottenere prestazioni ottimali, assicurarsi di creare anche in modo incrementale disabilitando qualsiasi opzione Pulisci dell'attività o dello strumento usato per la compilazione.

Se è necessario pulire il repository ,ad esempio per evitare problemi causati da file residui di una build precedente, le opzioni sono riportate di seguito.

Nota

La pulizia non è efficace se si usa un agente ospitato da Microsoft perché si otterrà un nuovo agente ogni volta. Quando si usano agenti self-hosted, a seconda della configurazione dei pool di agenti, è possibile ottenere un nuovo agente per le esecuzioni successive della pipeline (o fasi o processi nella stessa pipeline), quindi non è garantito che le esecuzioni, i processi o le fasi successive possano accedere agli output delle esecuzioni, dei processi o delle fasi precedenti.

YAML

Azure Pipelines, Azure DevOps Server 2019 e versioni successive

Sono disponibili diverse opzioni di pulizia per le pipeline YAML.

• Il checkout passaggio ha un'opzione clean . Se impostato su true, la pipeline viene eseguita execute git clean -ffdx && git reset --hard HEAD prima di recuperare il repository. Per altre informazioni, vedere Checkout.
• L'impostazione workspace per job include più opzioni pulite (output, risorse, tutto). Per altre informazioni, vedere Area di lavoro.
• L'interfaccia utente delle impostazioni della pipeline ha un'impostazione Pulita , che quando è impostata su true equivale a specificare clean: true per ogni checkout passaggio della pipeline. Per configurare l'impostazione Pulisci :

  1. Modificare la pipeline, scegliere ...e selezionare Trigger.

     

  2. Selezionare YAML, Recupera origini e configurare l'impostazione Pulisci desiderata. Il valore predefinito è true.

     

Per eseguire l'override delle impostazioni pulite quando si esegue manualmente una pipeline, è possibile usare i parametri di runtime. Nell'esempio seguente viene usato un parametro di runtime per configurare l'impostazione checkout clean.

parameters:
- name: clean
  displayName: Checkout clean
  type: boolean
  default: true
  values:
  - false
  - true

trigger:
- main

pool: FabrikamPool
#  vmImage: 'ubuntu-latest'

steps:
- checkout: self
  clean: ${{ parameters.clean }}

Per impostazione predefinita, clean è impostato su ma può essere sottoposto a true override quando si esegue manualmente la pipeline deselezionando la casella di controllo Checkout clean aggiunta per il parametro di runtime.

Classico

Azure Pipelines, TFS 2018, TFS 2017.2, TFS 2017.3

Selezionare una delle seguenti opzioni:

• Origini: la pipeline di compilazione esegue un annullamento delle modifiche apportate a $(Build.SourcesDirectory). In particolare, i comandi Git seguenti vengono eseguiti prima di recuperare l'origine.

  git clean -ffdx
  git reset --hard HEAD
  

• Origini e directory di output: stessa operazione dell'opzione Sources precedente, più: Elimina e ricrea $(Build.BinariesDirectory). Si noti che e $(Build.ArtifactStagingDirectory)$(Common.TestResultsDirectory) vengono sempre eliminati e ricreati prima di ogni compilazione indipendentemente da una di queste impostazioni.

• Directory Origini: elimina e ricrea $(Build.SourcesDirectory). Ciò comporta l'inizializzazione di un nuovo repository Git locale per ogni compilazione.

• Tutte le directory di compilazione: elimina e ricrea $(Agent.BuildDirectory). Ciò comporta l'inizializzazione di un nuovo repository Git locale per ogni compilazione.

Origini etichetta

È possibile etichettare i file di codice sorgente per consentire al team di identificare facilmente la versione di ogni file inclusa nella compilazione completata. È anche possibile specificare se il codice sorgente deve essere etichettato per tutte le compilazioni o solo per le compilazioni riuscite.

Nota

È possibile usare questa funzionalità solo quando il repository di origine nella compilazione è un repository GitHub o un repository Git o TFVC dal progetto.

Nel formato Etichetta è possibile usare variabili definite dall'utente e predefinite con ambito "Tutti". Per esempio:

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

Le prime quattro variabili sono predefinite. My.Variable può essere definito dall'utente nella scheda variabili.

La pipeline di compilazione etichetta le origini con un tag Git.

Alcune variabili di compilazione potrebbero produrre un valore che non è un'etichetta valida. Ad esempio, variabili come $(Build.RequestedFor) e $(Build.DefinitionName) possono contenere spazi vuoti. Se il valore contiene spazi vuoti, il tag non viene creato.

Dopo che le origini sono contrassegnate dalla pipeline di compilazione, un artefatto con riferimento Git refs/tags/{tag} viene aggiunto automaticamente alla compilazione completata. In questo modo, il team offre una tracciabilità aggiuntiva e un modo più semplice per spostarsi dalla compilazione al codice compilato. Il tag è considerato un artefatto di compilazione perché viene prodotto dalla compilazione. Quando la compilazione viene eliminata manualmente o tramite un criterio di conservazione, il tag viene eliminato anche.

Stato della compilazione del report (Azure Pipelines, TFS 2018 e versioni successive)

È possibile offrire al team una visualizzazione dello stato di compilazione dal repository di origine remoto.

Se le origini si trovano in un repository Git Di Azure Repos nel progetto, questa opzione visualizza una notifica nella tabella Codici per indicare se la compilazione sta passando o ha esito negativo. Lo stato della compilazione viene visualizzato nelle schede seguenti:

• File: indica lo stato della build più recente per il ramo selezionato.
• Commit: indica lo stato di compilazione di ogni commit(questo richiede l'abilitazione del trigger di integrazione continua (CI) per le compilazioni.
• Rami: indica lo stato della build più recente per ogni ramo.

Se si usano più pipeline di compilazione per lo stesso repository nel progetto, è possibile scegliere di abilitare questa opzione per una o più pipeline. Nel caso in cui questa opzione sia abilitata in più pipeline, la notifica nella tabella Codici indica lo stato della build più recente in tutte le pipeline. I membri del team possono fare clic sul badge sullo stato della compilazione per visualizzare lo stato di compilazione più recente per ognuna delle pipeline di compilazione.

GitHub

Se le origini si trovano in GitHub, questa opzione pubblica lo stato della compilazione in GitHub usando le API GitHub Checks o Status . Se la compilazione viene attivata da una richiesta pull di GitHub, è possibile visualizzare lo stato nella pagina richieste pull di GitHub. In questo modo è anche possibile impostare i criteri di stato all'interno di GitHub e automatizzare le unioni. Se la compilazione viene attivata dall'integrazione continua (CI), è possibile visualizzare lo stato di compilazione nel commit o nel ramo in GitHub.

Altri tipi di repository remoti Git

Se l'origine si trova in qualsiasi altro tipo di repository remoto, non è possibile usare Azure Pipelines o TFS per pubblicare automaticamente lo stato della compilazione in tale repository. Tuttavia, è possibile usare una notifica di compilazione come modo per integrare e mostrare lo stato di compilazione all'interno delle esperienze di controllo della versione.

Percorso di estrazione

Se si estrae un singolo repository, per impostazione predefinita, il codice sorgente verrà estratto in una directory denominata s. Per le pipeline YAML, è possibile modificarlo specificando checkout con .path Il percorso specificato è relativo a $(Agent.BuildDirectory). Ad esempio: se il valore del percorso di estrazione è e $(Agent.BuildDirectory) è mycustompathC:\agent\_work\1, il codice sorgente verrà estratto in C:\agent\_work\1\mycustompath.

Se si usano più checkout passaggi e si estraeno più repository e non si specifica in modo esplicito la cartella usando path, ogni repository viene inserito in una sottocartella denominata s dopo il repository. Ad esempio, se si estraeno due repository denominati tools e code, il codice sorgente verrà estratto in C:\agent\_work\1\s\tools e C:\agent\_work\1\s\code.

Si noti che il valore del percorso di estrazione non può essere impostato in modo da salire i livelli di directory sopra , quindi path\..\anotherpath comporterà un percorso di estrazione valido (ad esempio C:\agent\_work\1\anotherpath), ma un valore come ..\invalidpath non sarà (ad esempioC:\agent\_work\invalidpath).$(Agent.BuildDirectory)

Se si usano più checkout passaggi ed estraendo più repository e si vuole specificare in modo esplicito la cartella usando path, è consigliabile evitare di impostare il percorso di un altro passaggio di checkout (ad esempio C:\agent\_work\1\s\repo1 e C:\agent\_work\1\s\repo1\repo2), in caso contrario, la sottocartella del passaggio di estrazione verrà cancellata dalla pulizia di un altro repository. Si noti che questo caso è valido se l'opzione clean è true per repo1)

Nota

Il percorso di estrazione può essere specificato solo per le pipeline YAML. Per altre informazioni, vedere Estrazione nello schema YAML.

Eseguire il checkout dei moduli secondari

Selezionare se si desidera scaricare i file dai moduli secondari. È possibile scegliere di ottenere i moduli secondari immediati o tutti i moduli secondari annidati in qualsiasi profondità di ricorsione. Se si vuole usare LFS con moduli secondari, assicurarsi di visualizzare la nota sull'uso di LFS con moduli secondari.

Nota

Per altre informazioni sulla sintassi YAML per il controllo dei moduli secondari, vedere Checkout in the YAML schema .For more information about the YAML syntax for check out submodules, see Checkout in the YAML schema.

La pipeline di compilazione estrae i moduli secondari Git purché siano:

• Non autenticato: repository pubblico non autenticato senza credenziali necessarie per clonare o recuperare.

• Autenticato:

  • Contenuto nello stesso progetto, nell'organizzazione GitHub o nell'account Bitbucket Cloud del repository Git specificato in precedenza.

  • Aggiunta usando un URL relativo al repository principale. Ad esempio, questa operazione verrà estratta: git submodule add /../../submodule.git mymodule questa non verrà estratta: git submodule add https://dev.azure.com/fabrikamfiber/_git/ConsoleApp mymodule

Moduli secondari autenticati

Nota

Assicurarsi di aver registrato i moduli secondari usando HTTPS e non usando SSH.

Le stesse credenziali usate dall'agente per ottenere le origini dal repository principale vengono usate anche per ottenere le origini per i moduli secondari.

Se il repository principale e i moduli secondari si trovano in un repository Git di Azure Repos nel progetto Azure DevOps, è possibile selezionare l'account usato per accedere alle origini. Nella scheda Opzioni, nel menu Ambito di autorizzazione del processo di compilazione selezionare una delle opzioni seguenti:

• Raccolta di progetti per usare l'account del servizio Compilazione raccolta progetti

• Progetto corrente per l'uso dell'account del servizio di compilazione del progetto .

Assicurarsi che l'account usato abbia accesso sia al repository principale che ai moduli secondari.

Se il repository principale e i moduli secondari si trovano nella stessa organizzazione GitHub, il token archiviato nella connessione al servizio GitHub viene usato per accedere alle origini.

Alternativa all'uso dell'opzione Checkout submodules

In alcuni casi non è possibile usare l'opzione Checkout submodules . Potrebbe essere presente uno scenario in cui è necessario un set diverso di credenziali per accedere ai moduli secondari. Ciò può verificarsi, ad esempio, se il repository principale e i repository del modulo secondario non vengono archiviati nella stessa organizzazione di Azure DevOps o nello stesso servizio Git.

Se non è possibile usare l'opzione Moduli secondari Checkout, è invece possibile usare un passaggio di script personalizzato per recuperare i moduli secondari. Prima di tutto, ottenere un token di accesso personale (PAT) e anteporre il prefisso con pat:. Codificare quindi in base64 questa stringa con prefisso per creare un token di autenticazione di base. Aggiungere infine questo script alla pipeline:

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: basic <BASE64_ENCODED_TOKEN_DESCRIBED_ABOVE>" submodule update --init --recursive

Assicurarsi di sostituire "<BASIC_AUTH_TOKEN>" con il token con codifica Base64.

Usare una variabile privata nel progetto o nella pipeline di compilazione per archiviare il token di autenticazione di base generato. Usare tale variabile per popolare il segreto nel comando Git precedente.

Nota

D: Perché non è possibile usare un gestore delle credenziali Git nell'agente?R: L'archiviazione delle credenziali del modulo secondario in un gestore credenziali Git installato nell'agente di compilazione privato non è in genere efficace perché gestione credenziali potrebbe richiedere di immettere nuovamente le credenziali ogni volta che il modulo secondario viene aggiornato. Questo non è consigliabile durante le compilazioni automatizzate quando l'interazione dell'utente non è possibile.

Estrai file da LFS

Selezionare se si desidera scaricare file da archiviazione file di grandi dimensioni.Select if you want to download files from large file storage (LFS).

Nell'editor classico selezionare la casella di controllo per abilitare questa opzione.

In una compilazione YAML aggiungere un passaggio di estrazione con lfs impostato su true:

steps:
- checkout: self
  lfs: true

Se si usa TFS o se si usa Azure Pipelines con un agente self-hosted, è necessario eseguire l'installazione git-lfs nell'agente per consentire il funzionamento di questa opzione. Se gli agenti ospitati usano Windows, è consigliabile usare la System.PreferGitFromPath variabile per assicurarsi che le pipeline usino le versioni di git e git-lfs installate nel computer. Per altre informazioni, vedere Quale versione di Git viene eseguita dall'agente?

Uso di Git LFS con moduli secondari

Se un modulo secondario contiene file LFS, è necessario configurare Git LFS prima di estrarne i moduli secondari. Gli agenti macOS e Linux ospitati da Microsoft sono preconfigurati in questo modo. Gli agenti Windows e gli agenti macOS/Linux self-hosted potrebbero non essere.

Come soluzione alternativa, se si usa YAML, è possibile aggiungere il passaggio seguente prima checkoutdi :

steps:
- script: |
    git config --global --add filter.lfs.required true
    git config --global --add filter.lfs.smudge "git-lfs smudge -- %%f"
    git config --global --add filter.lfs.process "git-lfs filter-process"
    git config --global --add filter.lfs.clean "git-lfs clean -- %%f"
  displayName: Configure LFS for use with submodules
- checkout: self
  lfs: true
  submodules: true
# ... rest of steps ...

Clonare un secondo repository

Per impostazione predefinita, la pipeline è associata a un repository da Azure Repos o da un provider esterno. Si tratta del repository che può attivare compilazioni su commit e richieste pull.

È possibile includere origini da un secondo repository nella pipeline. A tale scopo, scrivere uno script.

git clone https://github.com/Microsoft/TypeScript.git

Se il repository non è pubblico, sarà necessario passare l'autenticazione al comando Git.

Azure Repos

È possibile clonare più repository nello stesso progetto della pipeline usando il checkout multi-repository.

Se è necessario clonare un repository da un altro progetto non pubblico, sarà necessario eseguire l'autenticazione come utente che ha accesso a tale progetto.

Nota

Usare una variabile privata per archiviare le credenziali in modo sicuro.

Le variabili segrete non vengono rese automaticamente disponibili agli script come variabili di ambiente. Vedere Variabili segrete su come eseguirne il mapping.

Per Azure Repos, è possibile usare un token di accesso personale con l'autorizzazione Codice (lettura). Invia come campo password in un'intestazione di autorizzazione "Basic" senza un nome utente. In altre parole, codifica base64 il valore di :<PAT>, inclusi i due punti.

AUTH=$(echo -n ":$REPO_PAT" | openssl base64 | tr -d '\n')
git -c http.<repo URL>.extraheader="AUTHORIZATION: basic $AUTH" clone <repo URL> --no-checkout --branch master

Non sincronizzare le origini

I processi non di distribuzione recuperano automaticamente le origini. Usare questa opzione se si vuole ignorare questo comportamento. Questa opzione può essere utile nei casi in cui si vuole:

• Git init, config e fetch usando le proprie opzioni personalizzate.

• Usare una pipeline di compilazione per eseguire semplicemente l'automazione (ad esempio alcuni script) che non dipende dal codice nel controllo della versione.

Se si desidera disabilitare il download delle origini:

• Azure Pipelines, TFS 2018 e versioni successive: fare clic su Impostazioni avanzate e quindi selezionare Non sincronizzare le origini.

Nota

Quando si usa questa opzione, l'agente ignora anche l'esecuzione di comandi Git che puliscono il repository.

Recupero superficiale

Selezionare se si vuole limitare la durata del download nella cronologia. In effetti, questo comporta git fetch --depth=n. Se il repository è di grandi dimensioni, questa opzione potrebbe rendere più efficiente la pipeline di compilazione. Il repository potrebbe essere di grandi dimensioni se è stato usato per molto tempo e ha una cronologia ridimensionabile. Potrebbe anche essere di grandi dimensioni se sono stati aggiunti e successivamente eliminati file di grandi dimensioni.

In questi casi questa opzione consente di risparmiare risorse di rete e archiviazione. Potrebbe anche risparmiare tempo. Il motivo per cui non sempre risparmiare tempo è dovuto al fatto che in alcune situazioni il server potrebbe dover dedicare tempo a calcolare i commit da scaricare per la profondità specificata.

Nota

Quando la compilazione viene accodata, il ramo da compilare viene risolto in un ID commit. Quindi, l'agente recupera il ramo ed estrae il commit desiderato. Esiste una finestra di piccole dimensioni tra quando un ramo viene risolto in un ID commit e quando l'agente esegue il checkout. Se il ramo viene aggiornato rapidamente e si imposta un valore molto piccolo per il recupero superficiale, il commit potrebbe non esistere quando l'agente tenta di estrarlo. In tal caso, aumentare l'impostazione della profondità di recupero superficiale.

Dopo aver selezionato la casella di controllo per abilitare questa opzione, nella casella Profondità specificare il numero di commit.

Suggerimento

La Agent.Source.Git.ShallowFetchDepth variabile indicata di seguito funziona anche ed esegue l'override dei controlli della casella di controllo. In questo modo è possibile modificare l'impostazione quando si accoda la compilazione.

Preferire Git dal percorso

Per impostazione predefinita, l'agente di Windows usa la versione di Git in bundle con il software agente. Microsoft consiglia di usare la versione di Git in bundle con l'agente, ma sono disponibili diverse opzioni per eseguire l'override di questo comportamento predefinito e usare la versione di Git installata dal computer agente nel percorso.

• Impostare una variabile della pipeline denominata System.PreferGitFromPath su true nelle pipeline.
• Negli agenti self-hosted è possibile creare un file denominato .env nella directory radice dell'agente e aggiungere una System.PreferGitFromPath=true riga al file. Per altre informazioni, vedere Ricerca per categorie impostare variabili di ambiente diverse per ogni singolo agente?

Per visualizzare la versione di Git usata da una pipeline, è possibile esaminare i log per un checkout passaggio nella pipeline, come illustrato nell'esempio seguente.

Syncing repository: PathFilter (Git)
Prepending Path environment variable with directory containing 'git.exe'.
git version
git version 2.26.2.windows.1

Questa impostazione è sempre true sugli agenti non Windows.

Opzioni di trigger per altri git

Quando si specifica un repository Git altro/esterno, le compilazioni CI richiedono che il repository sia accessibile da Internet. Se il repository si trova dietro un firewall o un proxy, funzioneranno solo le compilazioni pianificate e manuali.

Domande frequenti

Quali protocolli possono essere usati dall'agente di compilazione con Git?

L'agente supporta HTTPS.

L'agente non supporta ancora SSH. Vedere Consenti alla compilazione di usare l'autenticazione SSH durante il controllo dei moduli secondari Git.