Condividi tramite

Creare repository Git Git o TFS di Azure Repos

  • Articolo

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

Azure Pipelines può compilare e convalidare automaticamente ogni richiesta pull ed eseguire il commit nel repository Git di Azure Repos.

Scegliere un repository da compilare

Per creare una nuova pipeline, selezionare prima un repository e quindi un file YAML in tale repository. Il repository in cui è presente il file YAML è denominato self repository. Per impostazione predefinita, si tratta del repository che verrà compilato dalla pipeline.

In un secondo momento è possibile configurare la pipeline per l'estrazione di un repository o di più repository diversi. Per informazioni su come eseguire questa operazione, vedere Checkout multi-repo.

È necessario concedere ad Azure Pipelines l'accesso ai repository per attivare le compilazioni e recuperare il codice durante le compilazioni. In genere, una pipeline ha accesso ai repository nello stesso progetto. Tuttavia, se si vuole accedere ai repository in un progetto diverso, è necessario aggiornare le autorizzazioni concesse ai token di accesso ai processi.

Trigger CI

I trigger di integrazione continua (CI) causano l'esecuzione di una pipeline ogni volta che si esegue il push di un aggiornamento nei rami specificati o si esegue il push dei tag specificati.

Le pipeline YAML vengono configurate per impostazione predefinita con un trigger CI in tutti i rami, a meno che l'impostazione Disabilita trigger CI YAML implicito, introdotta nello sprint 227 di Azure DevOps, non sia abilitata. L'impostazione Del trigger CI YAML implicito può essere configurata a livello di organizzazione o a livello di progetto. Quando l'impostazione disabilita il trigger CI YAML implicito è abilitata, i trigger CI per le pipeline YAML non sono abilitati se la pipeline YAML non include una trigger sezione. Per impostazione predefinita, il trigger CI YAML implicito non è abilitato.

Rami

È possibile controllare quali rami ottengono trigger CI con una sintassi semplice:

trigger:
- main
- releases/*

È possibile specificare il nome completo del ramo ( ad esempio , main) o un carattere jolly (ad esempio, releases/*). Per informazioni sulla sintassi con caratteri jolly, vedere Caratteri jolly.

Nota

Non è possibile usare le variabili nei trigger, perché le variabili vengono valutate in fase di esecuzione (dopo che il trigger è stato attivato).

Nota

Se si usano modelli per creare file YAML, è possibile specificare solo i trigger nel file YAML principale per la pipeline. Non è possibile specificare trigger nei file modello.

Per i trigger più complessi che usano exclude o batch, è necessario usare la sintassi completa, come illustrato nell'esempio seguente.

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

Nell'esempio precedente, la pipeline verrà attivata se viene eseguito il push di una modifica in main o in qualsiasi ramo di rilascio. Tuttavia, non verrà attivato se viene apportata una modifica a un ramo delle versioni che inizia con old.

Se si specifica una exclude clausola senza clausola include , equivale a specificare * nella include clausola .

Oltre a specificare i nomi dei rami negli branches elenchi, è anche possibile configurare i trigger in base ai tag usando il formato seguente:

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

Se non sono stati specificati trigger e l'impostazione Disabilita trigger CI YAML implicito non è abilitata, il valore predefinito è come se fosse stato scritto:

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Importante

Quando si specifica un trigger, sostituisce il trigger implicito predefinito e solo i push ai rami configurati in modo esplicito da includere attiveranno una pipeline. Le inclusioni vengono elaborate per prime e quindi le esclusioni vengono rimosse da tale elenco.

Invio in batch di esecuzioni CI

Se si hanno molti membri del team che caricano spesso le modifiche, è consigliabile ridurre il numero di esecuzioni avviate. Se si imposta su batch true, quando una pipeline è in esecuzione, il sistema attende fino al completamento dell'esecuzione, quindi avvia un'altra esecuzione con tutte le modifiche non ancora compilate.

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

Nota

batch non è supportato nei trigger di risorse del repository.

Per chiarire questo esempio, si supponga che un push A in main ha causato l'esecuzione della pipeline precedente. Mentre la pipeline è in esecuzione, vengono eseguiti push aggiuntivi B e C si verificano nel repository. Questi aggiornamenti non avviano immediatamente nuove esecuzioni indipendenti. Dopo il completamento della prima esecuzione, tuttavia, tutti i push fino a quel punto di tempo vengono raggruppati insieme e viene avviata una nuova esecuzione.

Nota

Se la pipeline ha più processi e fasi, la prima esecuzione dovrebbe comunque raggiungere uno stato terminale completando o ignorando tutti i processi e le fasi prima che la seconda esecuzione possa essere avviata. Per questo motivo, è necessario prestare attenzione quando si usa questa funzionalità in una pipeline con più fasi o approvazioni. Se si vuole eseguire il batch delle compilazioni in questi casi, è consigliabile suddividere il processo CI/CD in due pipeline, una per la compilazione (con invio in batch) e una per le distribuzioni.

Percorsi

È possibile specificare i percorsi di file da includere o escludere.

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

Quando si specificano percorsi, è necessario specificare in modo esplicito i rami da attivare se si usa Azure DevOps Server 2019.1 o versione precedente. Non è possibile attivare una pipeline con solo un filtro di percorso; è inoltre necessario disporre di un filtro di ramo e i file modificati che corrispondono al filtro del percorso devono essere da un ramo che corrisponde al filtro di ramo. Se si usa Azure DevOps Server 2020 o versione successiva, è possibile omettere branches di filtrare tutti i rami insieme al filtro del percorso.

I caratteri jolly sono supportati per i filtri di percorso. Ad esempio, è possibile includere tutti i percorsi che corrispondono a src/app/**/myapp*. È possibile usare caratteri jolly (**, *o ?) quando si specificano filtri di percorso.

  • I percorsi vengono sempre specificati in relazione alla radice del repository.
  • Se non si impostano filtri di percorso, la cartella radice del repository viene inclusa in modo implicito per impostazione predefinita.
  • Se si esclude un percorso, non è possibile includerlo anche a meno che non venga qualificato in una cartella più approfondita. Ad esempio, se si esclude /tools , è possibile includere /tools/trigger-runs-on-these
  • L'ordine dei filtri di percorso non è importante.
  • I percorsi in Git fanno distinzione tra maiuscole e minuscole. Assicurarsi di usare lo stesso caso delle cartelle reali.
  • Non è possibile usare le variabili nei percorsi, perché le variabili vengono valutate in fase di esecuzione (dopo che il trigger è stato attivato).

Tag

Oltre a specificare tag negli branches elenchi come descritto nella sezione precedente, è possibile specificare direttamente i tag da includere o escludere:

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

Se non si specificano trigger di tag, per impostazione predefinita i tag non attiveranno le pipeline.

Importante

Se si specificano tag in combinazione con i filtri di ramo, il trigger verrà attivato se il filtro di ramo è soddisfatto o il filtro tag viene soddisfatto. Ad esempio, se un tag sottoposto a push soddisfa il filtro del ramo, la pipeline viene attivata anche se il tag viene escluso dal filtro tag, perché il push ha soddisfatto il filtro del ramo.

Rifiuto esplicito dell'integrazione continua

Disabilitazione del trigger CI

È possibile rifiutare esplicitamente i trigger di integrazione continua specificando trigger: none.

# A pipeline with no CI trigger
trigger: none

Importante

Quando si esegue il push di una modifica in un ramo, il file YAML in tale ramo viene valutato per determinare se deve essere avviata un'esecuzione CI.

Ignorare l'integrazione continua per i singoli push

È anche possibile indicare ad Azure Pipelines di ignorare l'esecuzione di una pipeline che normalmente viene attivata da un push. È sufficiente includere ***NO_CI*** nel messaggio di uno dei commit che fanno parte di un push e Azure Pipelines ignorerà l'esecuzione dell'integrazione continua per questo push.

È anche possibile indicare ad Azure Pipelines di ignorare l'esecuzione di una pipeline che normalmente viene attivata da un push. È sufficiente includere [skip ci] nel messaggio o nella descrizione di uno dei commit che fanno parte di un push e Azure Pipelines ignorerà l'esecuzione dell'integrazione continua per questo push. È anche possibile usare una delle varianti seguenti.

  • [skip ci] oppure [ci skip]
  • skip-checks: true oppure skip-checks:true
  • [skip azurepipelines] oppure [azurepipelines skip]
  • [skip azpipelines] oppure [azpipelines skip]
  • [skip azp] oppure [azp skip]
  • ***NO_CI***

Uso del tipo di trigger in condizioni

È uno scenario comune per eseguire passaggi, processi o fasi diverse nella pipeline a seconda del tipo di trigger che ha avviato l'esecuzione. A tale scopo, è possibile usare la variabile Build.Reasondi sistema . Ad esempio, aggiungere la condizione seguente al passaggio, al processo o alla fase per escluderla dalle convalide della richiesta pull.

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Comportamento dei trigger quando vengono creati nuovi rami

È comune configurare più pipeline per lo stesso repository. Ad esempio, potrebbe essere disponibile una pipeline per compilare la documentazione per l'app e un'altra per compilare il codice sorgente. È possibile configurare i trigger CI con filtri di ramo e filtri di percorso appropriati in ognuna di queste pipeline. Ad esempio, è possibile attivare una pipeline quando si esegue il push di un aggiornamento nella docs cartella e un'altra da attivare quando si esegue il push di un aggiornamento nel codice dell'applicazione. In questi casi, è necessario comprendere come vengono attivate le pipeline quando viene creato un nuovo ramo.

Ecco il comportamento quando si esegue il push di un nuovo ramo (che corrisponde ai filtri del ramo) nel repository:

  • Se la pipeline dispone di filtri di percorso, verrà attivata solo se il nuovo ramo include modifiche ai file che corrispondono al filtro di percorso.
  • Se la pipeline non dispone di filtri di percorso, verrà attivata anche se non sono presenti modifiche nel nuovo ramo.

Caratteri jolly

Quando si specifica un ramo, un tag o un percorso, è possibile usare un nome esatto o un carattere jolly. I criteri con caratteri jolly consentono di * trovare la corrispondenza con zero o più caratteri e ? di trovare una corrispondenza con un singolo carattere.

  • Se si avvia il modello con * in una pipeline YAML, è necessario eseguire il wrapping del modello tra virgolette, ad esempio "*-releases".
  • Per rami e tag:
    • Un carattere jolly può essere visualizzato in qualsiasi punto del modello.
  • Per i percorsi:
    • In Azure DevOps Server 2022 e versioni successive, incluso Azure DevOps Services, un carattere jolly può essere visualizzato ovunque all'interno di un modello di percorso ed è possibile usare * o ?.
    • In Azure DevOps Server 2020 e versioni precedenti è possibile includere * come carattere finale, ma non esegue alcuna operazione diversa dalla specifica del nome della directory da solo. Non è possibile includere * al centro di un filtro di percorso e non è possibile usare ?.
trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Trigger di richiesta pull

I trigger di richiesta pull causano l'esecuzione di una pipeline ogni volta che si apre una richiesta pull o quando si esegue il push delle modifiche. In Azure Repos Git questa funzionalità viene implementata usando i criteri di ramo. Per abilitare la convalida della richiesta pull, passare ai criteri di ramo per il ramo desiderato e configurare i criteri di convalida della compilazione per tale ramo. Per altre informazioni, vedere Configurare i criteri dei rami.

Se si dispone di una richiesta pull aperta e si esegue il push delle modifiche nel relativo ramo di origine, è possibile che vengano eseguite più pipeline:

  • Le pipeline specificate dai criteri di convalida della compilazione del ramo di destinazione verranno eseguite sul commit di merge (il codice unito tra i rami di origine e di destinazione della richiesta pull), indipendentemente dal fatto che esistano commit sottoposti a push i cui messaggi o descrizioni contengono [skip ci] (o una delle relative varianti).
  • Le pipeline attivate dalle modifiche apportate al ramo di origine della richiesta pull, se non sono presenti commit di cui è stato eseguito il push i cui messaggi o descrizioni contengono [skip ci] (o una delle relative varianti). Se almeno un commit sottoposto a push contiene [skip ci], le pipeline non verranno eseguite.

Infine, dopo aver unito la richiesta pull, Azure Pipelines eseguirà le pipeline di integrazione continua attivate dai push nel ramo di destinazione, anche se alcuni dei messaggi o delle descrizioni dei commit uniti contengono [skip ci] (o una delle relative varianti).

Nota

Per configurare le compilazioni di convalida per un repository Git di Azure Repos, è necessario essere un amministratore del progetto.

Nota

Le richieste pull bozza non attivano una pipeline anche se si configurano criteri di ramo.

Convalidare i contributi dai fork

La compilazione di richieste pull dai fork di Azure Repos non è diversa dalla compilazione di richieste pull all'interno dello stesso repository o progetto. È possibile creare fork solo all'interno della stessa organizzazione di cui fa parte il progetto.

Limitare l'ambito di autorizzazione del processo

Azure Pipelines offre diverse impostazioni di sicurezza per configurare l'ambito di autorizzazione del processo con cui vengono eseguite le pipeline.

Limita ambito di autorizzazione del processo al progetto corrente

Azure Pipelines offre due ambiti di autorizzazione per limitare l'autorizzazione del processo alle impostazioni correnti del progetto :

  • Limitare l'ambito di autorizzazione del processo al progetto corrente per le pipeline non di versione: questa impostazione si applica alle pipeline YAML e alle pipeline di compilazione classiche. Questa impostazione non si applica alle pipeline di versione classiche.
  • Limitare l'ambito di autorizzazione del processo al progetto corrente per le pipeline di versione: questa impostazione si applica solo alle pipeline di versione classiche.

Le pipeline vengono eseguite con token di accesso con ambito raccolta, a meno che non sia abilitata l'impostazione pertinente per il tipo di pipeline. Le impostazioni limita l'ambito di autorizzazione del processo consentono di ridurre l'ambito di accesso per tutte le pipeline al progetto corrente. Ciò può influire sulla pipeline se si accede a un repository Git Di Azure Repos in un progetto diverso nell'organizzazione.

Se il repository Git Azure Repos si trova in un progetto diverso da quello della pipeline e l'impostazione Limita ambito di autorizzazione del processo per il tipo di pipeline è abilitata, è necessario concedere l'autorizzazione all'identità del servizio di compilazione per la pipeline al secondo progetto. Per altre informazioni, vedere Gestire le autorizzazioni dell'account del servizio di compilazione.

Azure Pipelines offre un'impostazione di sicurezza per configurare l'ambito di autorizzazione del processo con cui vengono eseguite le pipeline.

  • Limitare l'ambito di autorizzazione del processo al progetto corrente: questa impostazione si applica alle pipeline YAML e alle pipeline di compilazione classiche. Questa impostazione non si applica alle pipeline di versione classiche.

Le pipeline vengono eseguite con token di accesso con ambito raccolta, a meno che non sia abilitato Limitare l'ambito di autorizzazione del processo al progetto corrente. Questa impostazione consente di ridurre l'ambito di accesso per tutte le pipeline al progetto corrente. Ciò può influire sulla pipeline se si accede a un repository Git Di Azure Repos in un progetto diverso nell'organizzazione.

Se il repository Git Azure Repos si trova in un progetto diverso rispetto alla pipeline e l'impostazione Limita ambito autorizzazione processo è abilitata, è necessario concedere l'autorizzazione all'identità del servizio di compilazione per la pipeline al secondo progetto. Per altre informazioni, vedere Ambito di autorizzazione processo.

Per altre informazioni su Limitare l'ambito di autorizzazione del processo, vedere Informazioni sui token di accesso ai processi.

Limitare l'ambito di autorizzazione del processo ai repository Azure DevOps a cui si fa riferimento

Le pipeline possono accedere a qualsiasi repository Di Azure DevOps nei progetti autorizzati, come descritto nella sezione precedente Limitare l'ambito di autorizzazione del processo al progetto corrente, a meno che non sia abilitato Limitare l'ambito di autorizzazione del processo ai repository Azure DevOps a cui si fa riferimento. Con questa opzione abilitata, è possibile ridurre l'ambito di accesso per tutte le pipeline solo ai repository Azure DevOps a cui fa riferimento in modo esplicito un checkout passaggio o un'istruzione uses nel processo della pipeline che usa tale repository.

Per configurare questa impostazione, passare a Pipeline, Impostazioni in Impostazioni organizzazione o Impostazioni progetto. Se abilitata a livello di organizzazione, l'impostazione è disattivata e non è disponibile a livello di impostazioni del progetto.

Quando è abilitato Limitare l'ambito di autorizzazione del processo ai repository Azure DevOps a cui si fa riferimento, le pipeline YAML devono fare riferimento in modo esplicito a qualsiasi repository Git Azure Repos che si vuole usare nella pipeline come passaggio di estrazione nel processo che usa il repository. Non sarà possibile recuperare il codice usando le attività di scripting e i comandi Git per un repository Git Di Azure Repos, a meno che non venga fatto riferimento esplicitamente a tale repository.

Esistono alcune eccezioni in cui non è necessario fare riferimento in modo esplicito a un repository Git di Azure Repos prima di usarlo nella pipeline quando è abilitato Limitare l'ambito di autorizzazione del processo ai repository Azure DevOps a cui si fa riferimento.

  • Se non si dispone di un passaggio di estrazione esplicito nella pipeline, è come se si disponesse di un checkout: self passaggio e il self repository viene estratto.
  • Se si usa uno script per eseguire operazioni di sola lettura in un repository in un progetto pubblico, non è necessario fare riferimento al repository del progetto pubblico in un checkout passaggio.
  • Se si usa uno script che fornisce la propria autenticazione al repository, ad esempio un token di accesso personale, non è necessario fare riferimento a tale repository in un checkout passaggio.

Ad esempio, quando è abilitato Limitare l'ambito di autorizzazione del processo ai repository Azure DevOps a cui si fa riferimento, se la pipeline si trova nel FabrikamProject/Fabrikam repository dell'organizzazione e si vuole usare uno script per controllare il FabrikamProject/FabrikamTools repository, è necessario fare riferimento a questo repository in un checkout passaggio o con un'istruzione uses .

Se si sta già eseguendo il check-out del FabrikamTools repository nella pipeline usando un passaggio di estrazione, è possibile usare successivamente script per interagire con tale repository.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo

# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools

steps:
- script: # Do something with that repo like clone it

Nota

Per molti scenari, è possibile sfruttare il checkout di più repository, eliminando la necessità di usare script per estrarre altri repository nella pipeline. Per altre informazioni, vedere Estrazione di più repository nella pipeline.

Proteggere l'accesso ai repository nelle pipeline YAML

Le pipeline possono accedere a qualsiasi repository Di Azure DevOps nei progetti autorizzati, come descritto nella sezione precedente Limitare l'ambito di autorizzazione del processo al progetto corrente, a meno che non sia abilitato Proteggere l'accesso ai repository nelle pipeline YAML. Con questa opzione abilitata, è possibile ridurre l'ambito di accesso per tutte le pipeline solo ai repository Azure DevOps a cui fa riferimento in modo esplicito un checkout passaggio o un'istruzione uses nel processo della pipeline che usa tale repository.

Per configurare questa impostazione, passare a Pipeline, Impostazioni in Impostazioni organizzazione o Impostazioni progetto. Se abilitata a livello di organizzazione, l'impostazione è disattivata e non è disponibile a livello di impostazioni del progetto.

Importante

Proteggere l'accesso ai repository nelle pipeline YAML è abilitato per impostazione predefinita per le nuove organizzazioni e i nuovi progetti creati dopo maggio 2020. Quando l'opzione Proteggi l'accesso ai repository nelle pipeline YAML è abilitata, le pipeline YAML devono fare riferimento in modo esplicito a qualsiasi repository Git Azure Repos che si vuole usare nella pipeline come passaggio di estrazione nel processo che usa il repository. Non sarà possibile recuperare il codice usando le attività di scripting e i comandi Git per un repository Git Di Azure Repos, a meno che non venga fatto riferimento esplicitamente a tale repository.

Esistono alcune eccezioni in cui non è necessario fare riferimento in modo esplicito a un repository Git di Azure Repos prima di usarlo nella pipeline quando è abilitato Proteggere l'accesso ai repository nelle pipeline YAML.

  • Se non si dispone di un passaggio di estrazione esplicito nella pipeline, è come se si disponesse di un checkout: self passaggio e il self repository viene estratto.
  • Se si usa uno script per eseguire operazioni di sola lettura in un repository in un progetto pubblico, non è necessario fare riferimento al repository del progetto pubblico in un checkout passaggio.
  • Se si usa uno script che fornisce la propria autenticazione al repository, ad esempio un token di accesso personale, non è necessario fare riferimento a tale repository in un checkout passaggio.

Ad esempio, quando è abilitato Proteggere l'accesso ai repository nelle pipeline YAML, se la pipeline si trova nel FabrikamProject/Fabrikam repository dell'organizzazione e si vuole usare uno script per controllare il FabrikamProject/FabrikamTools repository, è necessario fare riferimento a questo repository in un checkout passaggio o con un'istruzione uses .

Se si sta già eseguendo il check-out del FabrikamTools repository nella pipeline usando un passaggio di estrazione, è possibile usare successivamente script per interagire con tale repository.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it

Nota

Per molti scenari, è possibile sfruttare il checkout di più repository, eliminando la necessità di usare script per estrarre altri repository nella pipeline. Per altre informazioni, vedere Estrazione di più repository nella pipeline.

Checkout

Quando viene attivata una pipeline, Azure Pipelines esegue il pull del codice sorgente dal repository Git Azure Repos. È possibile controllare vari aspetti del modo in cui si verifica questo problema.

Nota

Quando si include un passaggio di estrazione nella pipeline, viene eseguito il comando seguente: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1. Se questo non soddisfa le proprie esigenze, è possibile scegliere di escludere il checkout predefinito da checkout: none e quindi usare un'attività script per eseguire il proprio checkout.

Versione preferita di Git

L'agente di Windows viene fornito con la propria copia di Git. Se si preferisce specificare il proprio Git anziché usare la copia inclusa, impostare su System.PreferGitFromPath true. Questa impostazione è sempre true sugli agenti non Windows.

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) è mycustompath C:\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)

È possibile configurare l'impostazione path nel passaggio Checkout della pipeline.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Moduli secondari

È possibile configurare l'impostazione submodules nel passaggio Checkout della pipeline se si desidera scaricare i file dai moduli secondari.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

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 del repository Git Azure Repos specificato in precedenza. Le stesse credenziali usate dall'agente per ottenere le origini dal repository principale vengono usate anche per ottenere le origini per i moduli secondari.

    • Aggiunta usando un URL relativo al repository principale. Ad esempio:

      • Questo sarebbe stato estratto: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

        In questo esempio il modulo secondario fa riferimento a un repository (FabrikamFiber) nella stessa organizzazione di Azure DevOps, ma in un progetto diverso (FabrikamFiberProject). Le stesse credenziali usate dall'agente per ottenere le origini dal repository principale vengono usate anche per ottenere le origini per i moduli secondari. Ciò richiede che il token di accesso al processo abbia accesso al repository nel secondo progetto. Se è stato limitato il token di accesso al processo come illustrato nella sezione precedente, non sarà possibile eseguire questa operazione. È possibile consentire al token di accesso al processo di accedere al repository nel secondo progetto concedendo esplicitamente l'accesso all'account del servizio di compilazione del progetto nel secondo progetto o (b) usando token di accesso con ambito raccolta anziché token con ambito progetto per l'intera organizzazione. Per altre informazioni su queste opzioni e sulle relative implicazioni per la sicurezza, vedere Accedere a repository, artefatti e altre risorse.

      • Questo non verrà estratto: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

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 se il token di accesso al processo non ha accesso al repository in un progetto diverso.

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_STRING>" submodule update --init --recursive

Assicurarsi di sostituire "<BASE64_ENCODED_STRING>" con la stringa "pat: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? Un: 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.

Tag di sincronizzazione

Importante

La funzionalità dei tag di sincronizzazione è supportata in Azure Repos Git con Azure DevOps Server 2022.1 e versioni successive.

Il passaggio di estrazione usa l'opzione --tags quando si recupera il contenuto di un repository Git. In questo modo il server recupera tutti i tag e tutti gli oggetti a cui puntano tali tag. Ciò aumenta il tempo necessario per eseguire l'attività in una pipeline, in particolare se si dispone di un repository di grandi dimensioni con un numero di tag. Inoltre, il passaggio di estrazione sincronizza i tag anche quando si abilita l'opzione di recupero superficiale, eventualmente sconfiggendone lo scopo. Per ridurre la quantità di dati recuperati o estratti da un repository Git, Microsoft ha aggiunto una nuova opzione per controllare il comportamento dei tag di sincronizzazione. Questa opzione è disponibile sia nelle pipeline classiche che nelle pipeline YAML.

Se sincronizzare i tag quando si estrae un repository può essere configurato in YAML impostando la fetchTags proprietà e nell'interfaccia utente configurando l'impostazione Sincronizza tag .

È possibile configurare l'impostazione fetchTags nel passaggio Checkout della pipeline.

Per configurare l'impostazione in YAML, impostare la fetchTags proprietà .

steps:
- checkout: self
  fetchTags: true

È anche possibile configurare questa impostazione usando l'opzione Sincronizza tag nell'interfaccia utente delle impostazioni della pipeline.

  1. Modificare la pipeline YAML e scegliere Altre azioni, Trigger.

    Screenshot del menu altri trigger.

  2. Scegliere YAML, Recupera origini.

    Screenshot di Recupera origini.

  3. Configurare l'impostazione Sincronizza tag .

    Screenshot dell'impostazione Sincronizza tag.

Nota

Se si imposta fetchTags in modo esplicito nel checkout passaggio, tale impostazione assume la priorità rispetto all'impostazione configurata nell'interfaccia utente delle impostazioni della pipeline.

Comportamento predefinito

Nota

Se si imposta fetchTags in modo esplicito nel checkout passaggio, tale impostazione assume la priorità rispetto all'impostazione configurata nell'interfaccia utente delle impostazioni della pipeline.

Recupero superficiale

È possibile limitare il tempo di 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.

Importante

Le nuove pipeline create dopo l'aggiornamento dello sprint 2022 di Azure DevOps di settembre 209 sono abilitate per impostazione predefinita e configurate con una profondità pari a 1. In precedenza il valore predefinito non era quello di recuperare poco. Per controllare la pipeline, visualizzare l'impostazione di recupero superficiale nell'interfaccia utente delle impostazioni della pipeline, come descritto nella sezione seguente.

È possibile configurare l'impostazione fetchDepth nel passaggio Checkout della pipeline.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

È anche possibile configurare la profondità di recupero impostando l'opzione Profondità superficiale nell'interfaccia utente delle impostazioni della pipeline.

  1. Modificare la pipeline YAML e scegliere Altre azioni, Trigger.

    Screenshot del menu altri trigger.

  2. Scegliere YAML, Recupera origini.

    Screenshot di Recupera origini.

  3. Configurare l'impostazione di recupero Superficiale. Deselezionare Il recupero superficiale per disabilitare il recupero superficiale o selezionare la casella e immettere una profondità per abilitare il recupero superficiale.

    Screenshot delle opzioni.

Nota

Se si imposta fetchDepth in modo esplicito nel checkout passaggio, tale impostazione assume la priorità rispetto all'impostazione configurata nell'interfaccia utente delle impostazioni della pipeline. L'impostazione recupera tutta la cronologia fetchDepth: 0 ed esegue l'override dell'impostazione di recupero Superficiale.

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

All'avvio della pipeline, 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.

Non sincronizzare le origini

È possibile ignorare il recupero di nuovi commit. 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 dipendono dal codice nel controllo della versione.

È possibile configurare l'impostazione Don't sync sources (Non sincronizzare le origini) nel passaggio Checkout della pipeline impostando checkout: none .

steps:
- checkout: none  # Don't sync sources

Nota

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

Compilazione pulita

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

È possibile configurare l'impostazione clean nel passaggio Checkout della pipeline.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Quando clean è impostato sulla true pipeline di compilazione, esegue un annullamento di eventuali modifiche in $(Build.SourcesDirectory). In particolare, i comandi Git seguenti vengono eseguiti prima di recuperare l'origine.

git clean -ffdx
git reset --hard HEAD

Per altre opzioni, è possibile configurare l'impostazione workspace di un processo.

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

In questo modo vengono fornite le opzioni di pulizia seguenti.

  • output: stessa operazione dell'impostazione pulita descritta nell'attività di estrazione precedente, oltre a: 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.

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

  • all: 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.

Non è attualmente possibile configurare questa impostazione in YAML, ma è possibile nell'editor classico. Quando si modifica una pipeline YAML, è possibile accedere all'editor classico scegliendo Trigger dal menu dell'editor YAML.

Configurare le opzioni Git, YAML.

Nell'editor classico scegliere YAML, scegliere l'attività Recupera origini e quindi configurare le proprietà desiderate.

Nell'editor classico scegliere Get sources (Ottieni origini YAML > ).

Nel formato Tag è 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.

Domande frequenti

I problemi relativi all'integrazione di Azure Repos rientrano in tre categorie:

  • Trigger con errori: la pipeline non viene attivata quando si esegue il push di un aggiornamento al repository.
  • Checkout non riuscito: la pipeline viene attivata, ma ha esito negativo nel passaggio di estrazione.
  • Versione errata: la pipeline viene eseguita, ma usa una versione imprevista dell'origine/YAML.

Trigger con errori

È stata appena creata una nuova pipeline YAML con trigger CI/PR, ma la pipeline non viene attivata.

Seguire ognuno di questi passaggi per risolvere i problemi relativi ai trigger con errori:

  • Si sta configurando il trigger di richiesta pull nel file YAML o nei criteri di ramo per il repository? Per un repository Git di Azure Repos, non è possibile configurare un trigger di richiesta pull nel file YAML. È necessario usare i criteri dei rami.

  • La pipeline è sospesa o disabilitata? Aprire l'editor per la pipeline e quindi selezionare Impostazioni da controllare. Se la pipeline è sospesa o disabilitata, i trigger non funzionano.

  • Il file YAML è stato aggiornato nel ramo corretto? Se si esegue il push di un aggiornamento in un ramo, il file YAML in tale ramo regola il comportamento di integrazione continua. Se si esegue il push di un aggiornamento in un ramo di origine, il file YAML risultante dall'unione del ramo di origine con il ramo di destinazione determina il comportamento della richiesta pull. Assicurarsi che il file YAML nel ramo corretto disponga della configurazione CI o pr necessaria.

  • Il trigger è stato configurato correttamente? Quando si definisce un trigger YAML, è possibile specificare clausole di inclusione ed esclusione per rami, tag e percorsi. Assicurarsi che la clausola include corrisponda ai dettagli del commit e che la clausola exclude non le esclude. Controllare la sintassi per i trigger e assicurarsi che sia accurato.

  • Sono state usate variabili per definire il trigger o i percorsi? Questo non è supportato.

  • Sono stati usati modelli per il file YAML? In tal caso, assicurarsi che i trigger siano definiti nel file YAML principale. I trigger definiti all'interno dei file modello non sono supportati.

  • Sono stati esclusi i rami o i percorsi in cui è stato eseguito il push delle modifiche? Eseguire il test eseguendo il push di una modifica a un percorso incluso in un ramo incluso. Si noti che i percorsi nei trigger fanno distinzione tra maiuscole e minuscole. Assicurarsi di usare lo stesso caso di quelle delle cartelle reali quando si specificano i percorsi nei trigger.

  • È stato appena eseguito il push di un nuovo ramo? In tal caso, il nuovo ramo potrebbe non avviare una nuova esecuzione. Vedere la sezione "Comportamento dei trigger quando vengono creati nuovi rami".

I trigger CI o PR funzionano correttamente. Ma, hanno smesso di lavorare ora.

Prima di tutto, esaminare i passaggi per la risoluzione dei problemi nella domanda precedente. Seguire quindi questi passaggi aggiuntivi:

  • Sono presenti conflitti di unione nella richiesta pull? Per una richiesta pull che non ha attivato una pipeline, aprirla e verificare se presenta un conflitto di merge. Risolvere il conflitto di merge.

  • Si verifica un ritardo nell'elaborazione di eventi push o pull? In genere è possibile verificare questo problema verificando se il problema è specifico di una singola pipeline o è comune a tutte le pipeline o repository nel progetto. Se un aggiornamento push o una richiesta pull a uno dei repository presenta questo sintomo, potrebbero verificarsi ritardi nell'elaborazione degli eventi di aggiornamento. Controllare se si verifica un'interruzione del servizio nella pagina di stato. Se la pagina di stato mostra un problema, il team deve aver già iniziato a lavorare su di esso. Controllare frequentemente la pagina per gli aggiornamenti sul problema.

Non si vuole che gli utenti esestituiscono l'elenco dei rami per i trigger quando aggiornano il file YAML. Come posso fare?

Gli utenti con autorizzazioni per contribuire al codice possono aggiornare il file YAML ed escludere rami aggiuntivi. Di conseguenza, gli utenti possono includere la propria funzionalità o un ramo utente nel file YAML e eseguire il push di tale aggiornamento a una funzionalità o a un ramo utente. Ciò può causare l'attivazione della pipeline per tutti gli aggiornamenti di tale ramo. Se si vuole evitare questo comportamento, è possibile:

  1. Modificare la pipeline nell'interfaccia utente di Azure Pipelines.
  2. Passare al menu Trigger .
  3. Selezionare Override del trigger di integrazione continua YAML da qui.
  4. Specificare i rami da includere o escludere per il trigger.

Quando si seguono questi passaggi, tutti i trigger CI specificati nel file YAML vengono ignorati.

Nella pipeline YAML sono presenti più repository. Come si configurano i trigger per ogni repository?

Vedere Trigger in Uso di più repository.

Checkout non riuscito

Viene visualizzato l'errore seguente nel file di log durante il passaggio di estrazione. Come si risolve il problema?

remote: TF401019: The Git repository with name or identifier XYZ does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'XYZ' not found
##[error] Git fetch failed with exit code: 128

Seguire ognuno di questi passaggi per risolvere i problemi di checkout non riuscito:

  • Il repository esiste ancora? Prima di tutto, assicurarsi che lo faccia aprendolo nella pagina Repos .

  • Si accede al repository usando uno script? In tal caso, controllare l'impostazione Limita l'ambito di autorizzazione del processo per fare riferimento ai repository Di Azure DevOps. Quando è abilitato Limitare l'ambito di autorizzazione del processo ai repository Azure DevOps a cui si fa riferimento, non sarà possibile controllare i repository Git di Azure Repos usando uno script, a meno che non venga fatto riferimento in modo esplicito prima nella pipeline.

  • Qual è l'ambito di autorizzazione del processo della pipeline?

    • Se l'ambito è una raccolta:

      • Potrebbe trattarsi di un errore intermittente. Eseguire nuovamente la pipeline.
      • Un utente potrebbe aver rimosso l'accesso all'account del servizio di compilazione raccolta progetti.
        • Passare a Impostazioni progetto per il progetto in cui è presente il repository. Selezionare Repository repository > > specifici e quindi Sicurezza.
        • Controllare se il servizio di compilazione raccolta progetti (nome-raccolta) esiste nell'elenco degli utenti.
        • Controllare se l'account ha il tag Create e l'accesso in lettura .

    • Se l'ambito è project:

      • Il repository si trova nello stesso progetto della pipeline?
        • Sì:
          • Potrebbe trattarsi di un errore intermittente. Eseguire nuovamente la pipeline.
          • Un utente potrebbe aver rimosso l'accesso all'account del servizio di compilazione di Project.
            • Passare a Impostazioni progetto per il progetto in cui è presente il repository. Selezionare Repository repository > > specifici e quindi Sicurezza.
            • Controllare se il servizio di compilazione nome-progetto (nome-raccolta) esiste nell'elenco degli utenti.
            • Controllare se l'account ha il tag Create e l'accesso in lettura .
        • No:
          • La pipeline è in un progetto pubblico?
            • Sì: non è possibile accedere alle risorse esterne al progetto pubblico. Rendere privato il progetto.
            • No: è necessario configurare le autorizzazioni per accedere a un altro repository nella stessa raccolta di progetti.

Versione errata

Nella pipeline viene usata una versione errata del file YAML. Perché?

  • Per i trigger CI, il file YAML presente nel ramo di cui si esegue il push viene valutato per verificare se deve essere eseguita una compilazione CI.
  • Per i trigger pr, il file YAML risultante dall'unione dei rami di origine e di destinazione della richiesta pull viene valutato per verificare se deve essere eseguita una compilazione pull.