Repository GitHub

Servizi di Azure DevOps

Azure Pipelines può compilare e convalidare automaticamente ogni richiesta pull ed eseguire il commit nel repository GitHub. Questo articolo descrive come configurare l'integrazione tra GitHub e Azure Pipelines.

Se non si ha familiarità con l'integrazione delle pipeline con GitHub, seguire la procedura descritta in Creare la prima pipeline. Tornare a questo articolo per altre informazioni sulla configurazione e la personalizzazione dell'integrazione tra GitHub e Azure Pipelines.

Organizzazioni e utenti

GitHub e Azure Pipelines sono due servizi indipendenti che si integrano bene insieme. Ognuno di essi ha la propria organizzazione e la gestione degli utenti. Questa sezione fornisce indicazioni su come replicare l'organizzazione e gli utenti da GitHub in Azure Pipelines.

Organizzazioni

La struttura di GitHub è costituita da organizzazioni e account utente che contengono repository. Vedere la documentazione di GitHub.

La struttura di Azure DevOps è costituita da organizzazioni che contengono progetti. Vedere Pianificare la struttura organizzativa.

Azure DevOps può riflettere la struttura di GitHub con:

• Un'organizzazione DevOps per l'organizzazione GitHub o l'account utente
• DevOps Projects per i repository GitHub

Per configurare una struttura identica in Azure DevOps:

1. Creare un'organizzazione DevOps denominata in base all'organizzazione GitHub o all'account utente. Avrà un URL come https://dev.azure.com/your-organization.
2. Nell'organizzazione DevOps creare progetti denominati in base ai repository. Avranno URL come https://dev.azure.com/your-organization/your-repository.
3. Nel progetto DevOps creare pipeline denominate dopo l'organizzazione GitHub e il repository compilati, ad esempio your-organization.your-repository. Quindi, è chiaro per quali repository sono destinati.

Seguendo questo modello, i repository GitHub e Azure DevOps Projects avranno percorsi URL corrispondenti. Ad esempio:

Service	URL
GitHub	https://github.com/python/cpython
Azure DevOps	https://dev.azure.com/python/cpython

Utenti

Gli utenti di GitHub non ottengono automaticamente l'accesso ad Azure Pipelines. Azure Pipelines non è a conoscenza delle identità di GitHub. Per questo motivo, non è possibile configurare Azure Pipelines per notificare automaticamente agli utenti un errore di compilazione o un errore di convalida della richiesta pull usando l'identità GitHub e l'indirizzo di posta elettronica. È necessario creare in modo esplicito nuovi utenti in Azure Pipelines per replicare gli utenti di GitHub. Dopo aver creato nuovi utenti, è possibile configurare le relative autorizzazioni in Azure DevOps per riflettere le relative autorizzazioni in GitHub. È anche possibile configurare le notifiche in DevOps usando l'identità DevOps.

Ruoli dell'organizzazione gitHub

I ruoli membro dell'organizzazione GitHub sono disponibili in https://github.com/orgs/your-organization/people (sostituire your-organization).

Le autorizzazioni dei membri dell'organizzazione DevOps sono disponibili in https://dev.azure.com/your-organization/_settings/security (sostituire your-organization).

I ruoli in un'organizzazione GitHub e i ruoli equivalenti in un'organizzazione Azure DevOps sono illustrati di seguito.

Ruolo dell'organizzazione GitHub	Equivalente dell'organizzazione DevOps
Proprietario	Membro di Project Collection Administrators
Responsabile fatturazione	Membro di Project Collection Administrators
Member	Membro di Project Collection Valid Users. Per impostazione predefinita, il gruppo membro non dispone dell'autorizzazione per creare nuovi progetti. Per modificare l'autorizzazione, impostare l'autorizzazione del Create new projects gruppo su Allowo creare un nuovo gruppo con le autorizzazioni necessarie.

Ruoli dell'account utente gitHub

Un account utente GitHub ha un ruolo, ovvero la proprietà dell'account.

Le autorizzazioni dei membri dell'organizzazione DevOps sono disponibili in https://dev.azure.com/your-organization/_settings/security (sostituire your-organization).

Il ruolo dell'account utente GitHub esegue il mapping alle autorizzazioni dell'organizzazione DevOps come indicato di seguito.

Ruolo dell'account utente GitHub	Equivalente dell'organizzazione DevOps
Proprietario	Membro di Project Collection Administrators

Autorizzazioni del repository GitHub

Le autorizzazioni del repository GitHub sono disponibili in https://github.com/your-organization/your-repository/settings/collaboration (sostituire your-organization e your-repository).

Le autorizzazioni del progetto DevOps sono disponibili in https://dev.azure.com/your-organization/your-project/_settings/security (sostituire your-organization e your-project).

Le autorizzazioni equivalenti tra i repository GitHub e Azure DevOps Projects sono le seguenti.

Autorizzazione del repository GitHub	Equivalente al progetto DevOps
Amministratore	Membro di Project Administrators
Scrittura	Membro di Contributors
Lettura	Membro di Readers

Se il repository GitHub concede l'autorizzazione ai team, è possibile creare team corrispondenti nella Teams sezione delle impostazioni del progetto Azure DevOps. Aggiungere quindi i team ai gruppi di sicurezza precedenti, proprio come gli utenti.

Autorizzazioni specifiche della pipeline

Per concedere autorizzazioni a utenti o team per pipeline specifiche in un progetto DevOps, seguire questa procedura:

1. Visitare la pagina Pipeline del progetto , ad esempio https://dev.azure.com/your-organization/your-project/_build.
2. Selezionare la pipeline per cui impostare autorizzazioni specifiche.
3. Dal menu di scelta rapida '...' selezionare Sicurezza.
4. Selezionare Aggiungi per aggiungere un utente, un team o un gruppo specifico e personalizzarne le autorizzazioni per la pipeline.

Accesso ai repository GitHub

YAML

Per creare una nuova pipeline, selezionare prima un repository GitHub 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.

Classico

Per creare una nuova pipeline, selezionare prima GitHub per il tipo di repository e quindi uno dei repository a cui si ha accesso.

Azure Pipelines deve avere accesso ai repository per attivare le compilazioni e recuperare il codice durante le compilazioni.

Esistono tre tipi di autenticazione per concedere ad Azure Pipelines l'accesso ai repository GitHub durante la creazione di una pipeline.

Tipo di autenticazione	Le pipeline vengono eseguite con	Funziona con i controlli di GitHub
1. App GitHub	Identità di Azure Pipelines	Sì
2. OAuth	Identità personale di GitHub	No
3. Token di accesso personale (PAT)	Identità personale di GitHub	No

Autenticazione dell'app GitHub

L'app GitHub di Azure Pipelines è il tipo di autenticazione consigliato per le pipeline di integrazione continua. Dopo aver installato l'app GitHub nell'account GitHub o nell'organizzazione, la pipeline verrà eseguita senza usare l'identità personale di GitHub. Le compilazioni e gli aggiornamenti dello stato di GitHub verranno eseguiti usando l'identità di Azure Pipelines. L'app funziona con GitHub Checks per visualizzare i risultati di compilazione, test e code coverage in GitHub.

Per usare l'app GitHub, installarla nell'organizzazione GitHub o nell'account utente per alcuni o tutti i repository. L'app GitHub può essere installata e disinstallata dalla home page dell'app.

Dopo l'installazione, l'app GitHub diventerà il metodo predefinito di autenticazione di Azure Pipelines in GitHub (anziché OAuth) quando vengono create pipeline per i repository.

Se si installa l'app GitHub per tutti i repository in un'organizzazione GitHub, non è necessario preoccuparsi dell'invio di messaggi di posta elettronica di massa da parte di Azure Pipelines o della configurazione automatica delle pipeline per conto dell'utente. In alternativa all'installazione dell'app per tutti i repository, gli amministratori del repository possono installarla una alla volta per singoli repository. Questo richiede più lavoro per gli amministratori, ma non ha vantaggi né svantaggi.

Autorizzazioni necessarie in GitHub

Per l'installazione dell'app GitHub di Azure Pipelines è necessario essere un proprietario dell'organizzazione GitHub o un amministratore del repository. Inoltre, per creare una pipeline per un repository GitHub con l'integrazione continua e i trigger di richiesta pull, è necessario disporre delle autorizzazioni GitHub necessarie configurate. In caso contrario, il repository non verrà visualizzato nell'elenco di repository durante la creazione di una pipeline. A seconda del tipo di autenticazione e della proprietà del repository, assicurarsi che l'accesso appropriato sia configurato.

• Se il repository si trova nell'account GitHub personale, installare l'app GitHub di Azure Pipelines nell'account GitHub personale e sarà possibile elencare questo repository durante la creazione della pipeline in Azure Pipelines.

• Se il repository si trova nell'account GitHub personale di un altro utente, l'altra persona deve installare l'app GitHub di Azure Pipelines nel proprio account GitHub personale. È necessario essere aggiunti come collaboratore nelle impostazioni del repository in "Collaboratori". Accettare l'invito a essere un collaboratore usando il collegamento inviato tramite posta elettronica all'utente. Al termine, è possibile creare una pipeline per tale repository.

• Se il repository si trova in un'organizzazione GitHub di cui si è proprietari, installare l'app GitHub di Azure Pipelines nell'organizzazione GitHub. È anche necessario essere aggiunti come collaboratore oppure è necessario aggiungere il team nelle impostazioni del repository in "Collaboratori e team".

• Se il repository si trova in un'organizzazione GitHub di proprietà di un altro utente, un proprietario dell'organizzazione GitHub o un amministratore del repository deve installare l'app GitHub di Azure Pipelines nell'organizzazione. È necessario essere aggiunti come collaboratore oppure è necessario aggiungere il team nelle impostazioni del repository in "Collaboratori e team". Accettare l'invito a essere un collaboratore usando il collegamento inviato tramite posta elettronica all'utente.

Autorizzazioni dell'app GitHub

L'app GitHub richiede le autorizzazioni seguenti durante l'installazione:

Autorizzazione	Come Azure Pipelines usa l'autorizzazione
Accesso in scrittura al codice	Solo dopo l'azione intenzionale, Azure Pipelines semplifica la creazione di una pipeline eseguendo il commit di un file YAML in un ramo selezionato del repository GitHub.
Accesso in lettura ai metadati	Azure Pipelines recupererà i metadati di GitHub per visualizzare il repository, i rami e i problemi associati a una compilazione nel riepilogo della compilazione.
Accesso in lettura e scrittura ai controlli	Azure Pipelines leggerà e scriverà i propri risultati di compilazione, test e code coverage da visualizzare in GitHub.
Accesso in lettura e scrittura alle richieste pull	Solo dopo l'azione intenzionale, Azure Pipelines semplifica la creazione di una pipeline creando una richiesta pull per un file YAML di cui è stato eseguito il commit in un ramo selezionato del repository GitHub. Le pipeline recuperano i metadati delle richieste da visualizzare nei riepiloghi di compilazione associati alle richieste pull.

Risoluzione dei problemi di installazione dell'app GitHub

GitHub può visualizzare un errore, ad esempio:

You do not have permission to modify this app on your-organization. Please contact an Organization Owner.

Ciò significa che l'app GitHub è probabilmente già installata per l'organizzazione. Quando si crea una pipeline per un repository nell'organizzazione, l'app GitHub verrà usata automaticamente per connettersi a GitHub.

Creare pipeline in più organizzazioni e progetti Azure DevOps

Dopo aver installato l'app GitHub, è possibile creare pipeline per i repository dell'organizzazione in diverse organizzazioni e progetti Azure DevOps. Tuttavia, se si creano pipeline per un singolo repository in più organizzazioni Azure DevOps, solo le pipeline della prima organizzazione possono essere attivate automaticamente da commit o richieste pull di GitHub. Le compilazioni manuali o pianificate sono ancora possibili nelle organizzazioni secondarie di Azure DevOps.

Autenticazione OAuth

OAuth è il tipo di autenticazione più semplice da usare per i repository nell'account GitHub personale. Gli aggiornamenti dello stato di GitHub verranno eseguiti per conto dell'identità GitHub personale. Affinché le pipeline continuino a funzionare, l'accesso al repository deve rimanere attivo. Alcune funzionalità di GitHub, ad esempio Controlli, non sono disponibili con OAuth e richiedono l'app GitHub.

Per usare OAuth, selezionare Scegliere una connessione diversa sotto l'elenco dei repository durante la creazione di una pipeline. Selezionare quindi Autorizza per accedere a GitHub e autorizzare con OAuth. Una connessione OAuth verrà salvata nel progetto Azure DevOps per usarla in un secondo momento e usata nella pipeline in fase di creazione.

Autorizzazioni necessarie in GitHub

Per creare una pipeline per un repository GitHub con l'integrazione continua e i trigger di richiesta pull, è necessario disporre delle autorizzazioni GitHub necessarie configurate. In caso contrario, il repository non verrà visualizzato nell'elenco di repository durante la creazione di una pipeline. A seconda del tipo di autenticazione e della proprietà del repository, assicurarsi che l'accesso appropriato sia configurato.

• Se il repository si trova nell'account GitHub personale, almeno una volta, eseguire l'autenticazione a GitHub con OAuth usando le credenziali dell'account GitHub personale. Questa operazione può essere eseguita nelle impostazioni del progetto Azure DevOps in Connessioni al servizio Pipelines > > Nuova connessione > al servizio Autorizza GitHub > . Concedere ad Azure Pipelines l'accesso ai repository in "Autorizzazioni" qui.

• Se il repository si trova nell'account GitHub personale di un altro utente, almeno una volta, l'altra persona deve eseguire l'autenticazione in GitHub con OAuth usando le credenziali personali dell'account GitHub. Questa operazione può essere eseguita nelle impostazioni del progetto Azure DevOps in Connessioni al servizio Pipelines > > Nuova connessione > al servizio Autorizza GitHub > . L'altra persona deve concedere ad Azure Pipelines l'accesso ai propri repository in "Autorizzazioni" qui. È necessario essere aggiunti come collaboratore nelle impostazioni del repository in "Collaboratori". Accettare l'invito a essere un collaboratore usando il collegamento inviato tramite posta elettronica all'utente.

• Se il repository si trova in un'organizzazione GitHub di cui si è proprietari, almeno una volta, eseguire l'autenticazione a GitHub con OAuth usando le credenziali dell'account GitHub personale. Questa operazione può essere eseguita nelle impostazioni del progetto Azure DevOps in Connessioni al servizio Pipelines > > Nuova connessione > al servizio Autorizza GitHub > . Concedere l'accesso ad Azure Pipelines all'organizzazione in "Accesso all'organizzazione" qui. È necessario essere aggiunti come collaboratore oppure è necessario aggiungere il team nelle impostazioni del repository in "Collaboratori e team".

• Se il repository si trova in un'organizzazione GitHub proprietaria almeno una volta, un proprietario dell'organizzazione GitHub deve eseguire l'autenticazione in GitHub con OAuth usando le credenziali personali dell'account GitHub. Questa operazione può essere eseguita nelle impostazioni del progetto Azure DevOps in Connessioni al servizio Pipelines > > Nuova connessione > al servizio Autorizza GitHub > . Il proprietario dell'organizzazione deve concedere l'accesso ad Azure Pipelines all'organizzazione in "Accesso all'organizzazione" qui. È necessario essere aggiunti come collaboratore oppure è necessario aggiungere il team nelle impostazioni del repository in "Collaboratori e team". Accettare l'invito a essere un collaboratore usando il collegamento inviato tramite posta elettronica all'utente.

Revocare l'accesso OAuth

Dopo l'autorizzazione di Azure Pipelines all'uso di OAuth, per revocarlo in un secondo momento e impedire un ulteriore uso, vedere App OAuth nelle impostazioni di GitHub. È anche possibile eliminarlo dall'elenco delle connessioni al servizio GitHub nelle impostazioni del progetto Azure DevOps.

Autenticazione del token di accesso personale

Le reti APE sono in effetti uguali a OAuth, ma consentono di controllare quali autorizzazioni vengono concesse ad Azure Pipelines. Le compilazioni e gli aggiornamenti dello stato di GitHub verranno eseguiti per conto dell'identità personale di GitHub. Affinché le compilazioni continuino a funzionare, l'accesso al repository deve rimanere attivo.

Per creare un token di accesso personale, vedere Token di accesso personali nelle impostazioni di GitHub. Le autorizzazioni necessarie sono repo, admin:repo_hook, read:usere user:email. Queste sono le stesse autorizzazioni necessarie quando si usa OAuth in precedenza. Copiare il pat generato negli Appunti e incollarlo in una nuova connessione al servizio GitHub nelle impostazioni del progetto Azure DevOps. Per un richiamo futuro, denominare la connessione al servizio dopo il nome utente di GitHub. Sarà disponibile nel progetto Azure DevOps per usarlo in un secondo momento durante la creazione di pipeline.

Autorizzazioni necessarie in GitHub

Per creare una pipeline per un repository GitHub con l'integrazione continua e i trigger di richiesta pull, è necessario disporre delle autorizzazioni GitHub necessarie configurate. In caso contrario, il repository non verrà visualizzato nell'elenco di repository durante la creazione di una pipeline. A seconda del tipo di autenticazione e della proprietà del repository, assicurarsi che sia configurato l'accesso seguente.

• Se il repository si trova nell'account GitHub personale, il pat deve avere gli ambiti di accesso necessari in Token di accesso personali: repo, admin:repo_hook, read:usere user:email.

• Se il repository si trova nell'account GitHub personale di un altro utente, il pat deve avere gli ambiti di accesso necessari in Token di accesso personali: repo, admin:repo_hook, read:usere user:email. È necessario essere aggiunti come collaboratore nelle impostazioni del repository in "Collaboratori". Accettare l'invito a essere un collaboratore usando il collegamento inviato tramite posta elettronica all'utente.

• Se il repository si trova in un'organizzazione GitHub di cui si è proprietari, il token di accesso personale deve avere gli ambiti di accesso necessari in Token di accesso personali: repo, admin:repo_hook, read:usere user:email. È necessario essere aggiunti come collaboratore oppure è necessario aggiungere il team nelle impostazioni del repository in "Collaboratori e team".

• Se il repository si trova in un'organizzazione GitHub di proprietà di un altro utente, il token di accesso personale deve avere gli ambiti di accesso necessari in Token di accesso personali: repo, admin:repo_hook, read:usere user:email. È necessario essere aggiunti come collaboratore oppure è necessario aggiungere il team nelle impostazioni del repository in "Collaboratori e team". Accettare l'invito a essere un collaboratore usando il collegamento inviato tramite posta elettronica all'utente.

Revocare l'accesso PAT

Dopo aver autorizzato Azure Pipelines a usare un token di accesso personale per eliminarlo in un secondo momento e impedire un ulteriore uso, vedere Token di accesso personali nelle impostazioni di GitHub. È anche possibile eliminarlo dall'elenco delle connessioni al servizio GitHub nelle impostazioni del progetto Azure DevOps.

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.

YAML

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.

Classico

Selezionare Abilita integrazione continua nella scheda Trigger per abilitare questo trigger se si vuole che la compilazione venga eseguita ogni volta che un utente archivia il codice.

Modifiche in batch

Selezionare questa casella di controllo se sono presenti molti membri del team che caricano spesso le modifiche e si vuole ridurre il numero di compilazioni in esecuzione. Se si seleziona questa opzione, quando una compilazione è in esecuzione, il sistema attende fino al completamento dell'esecuzione e quindi accoda un'altra esecuzione di tutte le modifiche non ancora compilate.

È possibile raggruppare le modifiche e compilarle insieme.

Nota

Se si usa l'invio in batch con una pipeline YAML a più fasi, un'esecuzione deve raggiungere uno stato terminale prima di poter iniziare. Questo spesso non è consigliabile perché una pipeline a più fasi può passare attraverso le approvazioni e le fasi di distribuzione a esecuzione prolungata. In questi casi, è consigliabile seguire una di queste soluzioni:

• non usare l'invio in batch
• suddividere la pipeline in due pipeline separate: una per l'integrazione continua e una cd
• impostare le condizioni appropriate sulle fasi per ignorarle e fare in modo che un'esecuzione termini rapidamente

Filtri rami

È possibile specificare i rami in cui si desidera attivare le compilazioni. Se si desidera utilizzare caratteri jolly, digitare la specifica del ramo ( ad esempio features/modules/*, ) e quindi premere INVIO.

Filtri di percorso

Se il repository Git si trova in Azure Repos o TFS, è anche possibile specificare filtri di percorso per ridurre il set di file che si desidera attivare una compilazione.

Suggerimenti:

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

Esempio

Ad esempio, si vuole che la compilazione venga attivata dalle modifiche apportate a main e nella maggior parte dei rami di funzionalità, ma non da tutti. Non si vuole che le compilazioni vengano attivate anche dalle modifiche apportate ai file nella cartella degli strumenti.

Ignorare l'integrazione continua per i singoli commit

È 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 viene aperta una richiesta pull con uno dei rami di destinazione specificati o quando vengono eseguiti aggiornamenti a tale richiesta pull.

YAML

Rami

È possibile specificare i rami di destinazione durante la convalida delle richieste pull. Ad esempio, per convalidare le richieste pull destinate main a e releases/*, è possibile usare il trigger seguente pr .

pr:
- main
- releases/*

Questa configurazione avvia una nuova esecuzione la prima volta che viene creata una nuova richiesta pull e dopo ogni aggiornamento eseguito alla richiesta pull.

È possibile specificare il nome completo del ramo ( ad esempio , main) o un carattere jolly (ad esempio, releases/*).

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.

GitHub crea un nuovo riferimento quando viene creata una richiesta pull. Il riferimento punta a un commit di merge, ovvero il codice unito tra i rami di origine e di destinazione della richiesta pull. La pipeline di convalida della richiesta pull compila il commit a cui punta questo riferimento . Ciò significa che il file YAML usato per eseguire la pipeline è anche un merge tra l'origine e il ramo di destinazione. Di conseguenza, le modifiche apportate al file YAML nel ramo di origine della richiesta pull possono eseguire l'override del comportamento definito dal file YAML nel ramo di destinazione.

Se nel file YAML non pr vengono visualizzati trigger, le convalide delle richieste pull vengono abilitate automaticamente per tutti i rami, come se fosse stato scritto il trigger seguente pr . Questa configurazione attiva una compilazione quando viene creata una richiesta pull e quando i commit vengono inseriti nel ramo di origine di qualsiasi richiesta pull attiva.

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

Importante

Quando si specifica un pr trigger con un subset di rami, viene attivata una pipeline solo quando gli aggiornamenti vengono inseriti in tali rami.

Per i trigger più complessi che devono escludere determinati rami, è necessario usare la sintassi completa, come illustrato nell'esempio seguente. In questo esempio, le richieste pull vengono convalidate che la destinazione main o releases/* e il ramo releases/old* è escluso.

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

Percorsi

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

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

Suggerimenti:

• Azure Pipelines invia uno stato neutro a GitHub quando decide di non eseguire una compilazione di convalida a causa di una regola di esclusione del percorso. Questo fornisce una direzione chiara a GitHub che indica che Azure Pipelines ha completato l'elaborazione. Per altre informazioni, vedere Post neutral status to GitHub when a build is skipped .For more information, see Post neutral status to GitHub when a build is skipped.
• I caratteri jolly sono ora supportati con i 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).
• Azure Pipelines invia uno stato neutro a GitHub quando decide di non eseguire una compilazione di convalida a causa di una regola di esclusione del percorso.

Aggiornamenti di più richieste pull

È possibile specificare se più aggiornamenti di una richiesta pull devono annullare le esecuzioni di convalida in corso per la stessa richiesta pull. Il valore predefinito è true.

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

Convalida bozza richiesta pull

Per impostazione predefinita, i trigger di richiesta pull vengono attivati nelle richieste pull bozza e nelle richieste pull pronte per la revisione. Per disabilitare i trigger di richiesta pull per le richieste pull bozza, impostare la drafts proprietà su false.

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

Rifiuto esplicito della convalida della richiesta pull

È possibile rifiutare esplicitamente la convalida della richiesta pull specificando pr: none.

# no PR triggers
pr: none

Per altre informazioni, vedere Trigger pr nello schema YAML.

Nota

Se il pr trigger non viene attivato, seguire la procedura di risoluzione dei problemi nelle domande frequenti.

Classico

Selezionare il trigger di convalida della richiesta pull e selezionare la casella di controllo Abilita convalida della richiesta pull per abilitare le compilazioni nelle richieste pull.

È possibile specificare rami da includere ed escludere. Selezionare un nome di ramo dal menu a discesa e selezionare Includi o Escludi in base alle esigenze. Per i rami inclusi, una compilazione verrà attivata in ogni push a una richiesta pull destinata a tale ramo.

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 che dispongono di un trigger di richiesta pull nel ramo di destinazione della richiesta pull 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, se il messaggio o la descrizione del commit di merge non contiene [skip ci] (o una delle relative varianti).

Rami protetti

È possibile eseguire una compilazione di convalida con ogni richiesta di commit o pull destinata a un ramo e persino impedire l'unione delle richieste pull fino al completamento di una compilazione di convalida.

Per configurare le compilazioni di convalida obbligatorie per un repository GitHub, è necessario essere il proprietario, un collaboratore con il ruolo di amministratore o un membro dell'organizzazione GitHub con il ruolo Scrittura.

1. Prima di tutto, creare una pipeline per il repository e compilarla almeno una volta in modo che lo stato venga pubblicato in GitHub, rendendo quindi GitHub consapevole del nome della pipeline.

2. Seguire quindi la documentazione di GitHub per configurare i rami protetti nelle impostazioni del repository.

   Per il controllo dello stato, selezionare il nome della pipeline nell'elenco Controlli di stato.

   

Importante

Se la pipeline non viene visualizzata in questo elenco, verificare quanto segue:

• Si usa l'autenticazione dell'app GitHub
• La pipeline è stata eseguita almeno una volta nell'ultima settimana

Contributi provenienti da origini esterne

Se il repository GitHub è open source, è possibile rendere pubblico il progetto Azure DevOps in modo che chiunque possa visualizzare i risultati, i log e i risultati di compilazione della pipeline senza eseguire l'accesso. Quando gli utenti esterni all'organizzazione creano una copia tramite fork del repository e inviano richieste pull, possono visualizzare lo stato delle compilazioni che convalidano automaticamente tali richieste pull.

Quando si usano Azure Pipelines in un progetto pubblico quando si accettano contributi da origini esterne, tenere presenti le considerazioni seguenti.

• Restrizioni di accesso
• Convalidare i contributi dai fork
• Considerazioni importanti sulla sicurezza

Restrizioni di accesso

Tenere presenti le restrizioni di accesso seguenti quando si eseguono pipeline nei progetti pubblici di Azure DevOps:

• Segreti: per impostazione predefinita, i segreti associati alla pipeline non vengono resi disponibili per le convalide delle richieste pull dei fork. Vedere Convalidare i contributi dai fork.
• Accesso tra progetti: tutte le pipeline in un progetto pubblico di Azure DevOps vengono eseguite con un token di accesso limitato al progetto. Le pipeline in un progetto pubblico possono accedere a risorse come artefatti di compilazione o risultati di test solo all'interno del progetto e non in altri progetti dell'organizzazione Azure DevOps.
• Pacchetti di Azure Artifacts: se le pipeline devono accedere ai pacchetti da Azure Artifacts, è necessario concedere in modo esplicito l'autorizzazione all'account del servizio di compilazione del progetto per accedere ai feed del pacchetto.

Contributi dai fork

Importante

Queste impostazioni influiscono sulla sicurezza della pipeline.

Quando si crea una pipeline, viene attivata automaticamente per le richieste pull dai fork del repository. È possibile modificare questo comportamento, valutando attentamente il modo in cui influisce sulla sicurezza. Per abilitare o disabilitare questo comportamento:

1. Passare al progetto Azure DevOps. Selezionare Pipeline, individuare la pipeline e selezionare Modifica.
2. Selezionare la scheda Trigger . Dopo aver abilitato il trigger della richiesta pull, abilitare o disabilitare la casella di controllo Compila richieste pull dai fork di questo repository .

Per impostazione predefinita con le pipeline di GitHub, i segreti associati alla pipeline di compilazione non sono resi disponibili per le compilazioni di richieste pull dei fork. Questi segreti sono abilitati per impostazione predefinita con le pipeline di GitHub Enterprise Server. I segreti includono:

• Token di sicurezza con accesso al repository GitHub.
• Questi elementi, se la pipeline li usa:
  • Credenziali di connessione al servizio
  • File dalla libreria di file protetti
  • Variabili di compilazione contrassegnate come segreto

Per ignorare questa precauzione nelle pipeline di GitHub, abilitare la casella di controllo Rendi i segreti disponibili per le compilazioni di fork . Tenere presente l'effetto di questa impostazione sulla sicurezza.

Nota

Quando si abilitano le compilazioni fork per accedere ai segreti, Azure Pipelines per impostazione predefinita limita il token di accesso usato per le compilazioni fork. Ha accesso più limitato alle risorse aperte rispetto a un normale token di accesso. Per assegnare alla fork le stesse autorizzazioni delle compilazioni regolari, abilitare le compilazioni di fork hanno le stesse autorizzazioni delle normali compilazioni .

Per altre informazioni, vedere Protezione del repository - Forks.

È possibile definire centralmente il modo in cui le pipeline compilano richieste pull dai repository GitHub con fork usando il controllo Limita la compilazione di richieste pull dai repository GitHub con fork. È disponibile a livello di organizzazione e progetto. È possibile scegliere:

• Disabilitare la compilazione di richieste pull dai repository con fork
• Compilare in modo sicuro le richieste pull dai repository con fork
• Personalizzare le regole per la compilazione di richieste pull dai repository con fork

A partire da Sprint 229, per migliorare la sicurezza delle pipeline, Azure Pipelines non compila più automaticamente le richieste pull dai repository GitHub con fork. Per i nuovi progetti e organizzazioni, il valore predefinito dell'impostazione Limita le richieste pull dalla creazione tramite fork dei repository GitHub è Disabilita la compilazione di richieste pull dai repository con fork.

Quando si sceglie l'opzione Pull di compilazione sicura da repository con fork, tutte le pipeline, l'organizzazione o il progetto non possono rendere disponibili segreti per le compilazioni di richieste pull dai repository con fork, non possono rendere queste compilazioni con le stesse autorizzazioni delle normali compilazioni e devono essere attivate da un commento della richiesta pull. I progetti possono comunque decidere di non consentire alle pipeline di compilare tali richieste pull.

Quando si sceglie l'opzione Personalizza , è possibile definire come limitare le impostazioni della pipeline. Ad esempio, è possibile assicurarsi che tutte le pipeline richiedano un commento per creare una richiesta pull da un repository GitHub con fork, quando la richiesta pull appartiene a membri non del team e non collaboratori. Tuttavia, è possibile scegliere di consentire loro di rendere disponibili segreti a tali compilazioni. I progetti possono decidere di non consentire alle pipeline di compilare tali richieste pull o di compilarle in modo sicuro o di avere impostazioni ancora più restrittive di quelle specificate a livello di organizzazione.

Il controllo è disattivato per le organizzazioni esistenti. A partire da settembre 2023, le nuove organizzazioni dispongono di richieste pull di compilazione sicura dai repository con fork attivate per impostazione predefinita.

Considerazioni importanti sulla sicurezza

Un utente di GitHub può creare un fork del repository, modificarlo e creare una richiesta pull per proporre modifiche al repository. Questa richiesta pull potrebbe contenere codice dannoso da eseguire come parte della compilazione attivata. Questo codice può causare danni nei modi seguenti:

• Perdita di segreti dalla pipeline. Per ridurre questo rischio, non abilitare la casella di controllo Rendi i segreti disponibili per le compilazioni di fork se il repository è pubblico o non attendibile gli utenti possono inviare richieste pull che attivano automaticamente le compilazioni. L'opzione è disabilitata per impostazione predefinita.

• Compromettere il computer che esegue l'agente per rubare codice o segreti da altre pipeline. Per attenuare questo problema:

  • Usare un pool di agenti ospitato da Microsoft per compilare richieste pull dai fork. I computer dell'agente ospitati da Microsoft vengono eliminati immediatamente dopo il completamento di una compilazione, quindi non c'è alcun impatto duraturo se vengono compromessi.

  • Se è necessario usare un agente self-hosted, non archiviare segreti o eseguire altre compilazioni e versioni che usano segreti nello stesso agente, a meno che il repository non sia privato e non si consideri attendibile gli autori di richieste pull.

Trigger di commento

I collaboratori del repository possono commentare una richiesta pull per eseguire manualmente una pipeline. Ecco alcuni motivi comuni per cui è possibile eseguire questa operazione:

• È possibile che non si voglia creare automaticamente richieste pull da utenti sconosciuti fino a quando non è possibile esaminare le modifiche. Si vuole che uno dei membri del team esamini prima il codice e quindi esegua la pipeline. Questa operazione viene comunemente usata come misura di sicurezza durante la compilazione di codice fornito dai repository con fork.
• È possibile eseguire un gruppo di test facoltativo o una più compilazioni di convalida.

Per abilitare i trigger di commento, è necessario seguire i due passaggi seguenti:

1. Abilitare i trigger di richiesta pull per la pipeline e assicurarsi di non escludere il ramo di destinazione.
2. Nel portale Web di Azure Pipelines modificare la pipeline e scegliere Altre azioni, Trigger. Quindi, in Convalida della richiesta pull abilitare Richiedi commento di un membro del team prima di compilare una richiesta pull.
   • Scegliere Su tutte le richieste pull per richiedere il commento di un membro del team prima di compilare una richiesta pull. Con questo flusso di lavoro, un membro del team esamina la richiesta pull e attiva la compilazione con un commento dopo che la richiesta pull è considerata sicura.
   • Scegliere Solo per le richieste pull da membri non del team per richiedere il commento di un membro del team solo quando viene effettuata una richiesta pull da un membro non del team. In questo flusso di lavoro, un membro del team non necessita della revisione di un membro del team secondario per attivare una compilazione.

Con queste due modifiche, la compilazione di convalida della richiesta pull non verrà attivata automaticamente, a meno che non venga selezionata solo in caso di richieste pull da membri non del team e che la richiesta pull venga effettuata da un membro del team. Solo i proprietari e i collaboratori del repository con l'autorizzazione 'Write' possono attivare la compilazione commentando la richiesta pull con /AzurePipelines run o /AzurePipelines run <pipeline-name>.

I comandi seguenti possono essere eseguiti in Azure Pipelines nei commenti:

Comando	Risultato
/AzurePipelines help	Visualizzare la Guida per tutti i comandi supportati.
/AzurePipelines help <command-name>	Visualizzare la Guida per il comando specificato.
/AzurePipelines run	Eseguire tutte le pipeline associate a questo repository e i cui trigger non escludono questa richiesta pull.
/AzurePipelines run <pipeline-name>	Eseguire la pipeline specificata a meno che i trigger non escludano questa richiesta pull.

Nota

Per brevità, è possibile impostare come commento invece /azp di /AzurePipelines.

Importante

Le risposte a questi comandi verranno visualizzate nella discussione della richiesta pull solo se la pipeline usa l'app GitHub di Azure Pipelines.

Risolvere i problemi relativi ai trigger di commento della richiesta pull

Se si dispone delle autorizzazioni del repository necessarie, ma le pipeline non vengono attivate dai commenti, assicurarsi che l'appartenenza sia pubblica nell'organizzazione del repository o aggiungersi direttamente come collaboratore del repository. Le pipeline non possono visualizzare membri dell'organizzazione privata a meno che non siano collaboratori diretti o appartengano a un team che è un collaboratore diretto. È possibile modificare l'appartenenza all'organizzazione GitHub da privata a pubblica qui (sostituire Your-Organization con il nome dell'organizzazione): https://github.com/orgs/Your-Organization/people.

Esecuzioni informative

Un'esecuzione informativa indica che Azure DevOps non è riuscito a recuperare il codice sorgente di una pipeline YAML. Il recupero del codice sorgente viene eseguito in risposta a eventi esterni, ad esempio un commit sottoposto a push. Si verifica anche in risposta a trigger interni, ad esempio, per verificare se sono presenti modifiche al codice e avviare o meno un'esecuzione pianificata. Il recupero del codice sorgente può avere esito negativo per diversi motivi, con una limitazione frequente delle richieste da parte del provider di repository Git. L'esistenza di un'esecuzione informativa non significa necessariamente che Azure DevOps eseguirà la pipeline.

Un'esecuzione informativa è simile alla schermata seguente.

È possibile riconoscere un'esecuzione informativa con gli attributi seguenti:

• Lo stato è Canceled
• La durata è < 1s
• Il nome dell'esecuzione contiene uno dei testi seguenti:
  • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
  • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
  • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
  • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
• Il nome dell'esecuzione contiene in genere l'errore BitBucket/GitHub che ha causato l'esito negativo del caricamento della pipeline YAML
• Nessuna fase/processo/passaggi

Altre informazioni sulle esecuzioni informative.

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

YAML

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

Classico

Questa impostazione non è configurabile nell'editor classico. Il codice sorgente verrà estratto in una directory denominata s, che è relativa a $(Agent.BuildDirectory). Ad esempio: se $(Agent.BuildDirectory) è C:\agent\_work\1, il codice sorgente verrà estratto in C:\agent\_work\1\mycustompath.

Moduli secondari

YAML

È 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

Classico

È possibile configurare l'impostazione Sottomoduli dalle proprietà dell'attività Recupera origini nella pipeline se si desidera scaricare file da moduli secondari.

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 .

YAML

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

   

2. Scegliere YAML, Recupera origini.

   

3. Configurare l'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.

Classico

È possibile configurare l'impostazione Sincronizza tag dalle proprietà dell'attività Recupera origini nella pipeline.

Comportamento predefinito

• Per le pipeline esistenti create prima del rilascio dello sprint 209 di Azure DevOps, rilasciato nel mese di settembre 2022, l'impostazione predefinita per i tag di sincronizzazione rimane identica al comportamento esistente prima dell'aggiunta delle opzioni Tag di sincronizzazione, ovvero true.
• Per le nuove pipeline create dopo la versione 209 dello sprint di Azure DevOps, l'impostazione predefinita per i tag di sincronizzazione è false.

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.

YAML

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

   

2. Scegliere YAML, 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.

   

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.

Classico

È possibile configurare l'impostazione di recupero Superficiale dalle proprietà dell'attività Recupera origini nella pipeline.

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.

YAML

È 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

Classico

Selezionare l'impostazione Non sincronizzare le origini dalle proprietà dell'attività Recupera origini nella pipeline.

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.

YAML

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

Classico

Selezionare l'impostazione Pulisci dalle proprietà dell'attività Recupera origini nella pipeline e selezionare una delle opzioni seguenti.

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

YAML

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.

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

Classico

È possibile configurare l'impostazione Origini tag dalle proprietà dell'attività Recupera origini nella pipeline.

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.

Variabili predefinite

Quando si compila un repository GitHub, la maggior parte delle variabili predefinite è disponibile per i processi. Tuttavia, poiché Azure Pipelines non riconosce l'identità di un utente che esegue un aggiornamento in GitHub, le variabili seguenti sono impostate sull'identità di sistema anziché sull'identità dell'utente:

• Build.RequestedFor
• Build.RequestedForId
• Build.RequestedForEmail

Aggiornamenti dello stato

Esistono due tipi di stati di cui Azure Pipelines esegue il postback a GitHub: stati di base e esecuzioni di controllo di GitHub. La funzionalità Di controllo di GitHub è disponibile solo con Le app GitHub.

Gli stati della pipeline vengono visualizzati in varie posizioni nell'interfaccia utente di GitHub.

• Per le richieste pull, vengono visualizzate nella scheda Conversazioni pull.
• Per i singoli commit, vengono visualizzati quando si passa il puntatore del mouse sul contrassegno di stato dopo il tempo di commit nella scheda commit del repository.

Connessioni PAT o GitHub OAuth

Per le pipeline che usano connessioni PAT o GitHub OAuth , gli stati vengono inviati al commit/richiesta pull che ha attivato l'esecuzione. L'API di stato di GitHub viene usata per pubblicare tali aggiornamenti. Questi stati contengono informazioni limitate: stato della pipeline (esito negativo, esito positivo), URL da collegare alla pipeline di compilazione e una breve descrizione dello stato.

Gli stati per le connessioni PAT o GitHub OAuth vengono inviati solo a livello di esecuzione. In altre parole, è possibile avere un singolo stato aggiornato per un'intera esecuzione. Se si hanno più processi in un'esecuzione, non è possibile pubblicare uno stato separato per ogni processo. Tuttavia, più pipeline possono pubblicare stati separati allo stesso commit.

Controlli di GitHub

Per le pipeline configurate usando l'app GitHub Azure Pipelines, lo stato viene pubblicato sotto forma di controlli GitHub. I controlli di GitHub consentono di inviare informazioni dettagliate sullo stato e sui test della pipeline, il code coverage e gli errori. L'API GitHub Checks è disponibile qui.

Per ogni pipeline che usa l'app GitHub, i controlli vengono inviati di nuovo per l'esecuzione complessiva e per ogni processo in tale esecuzione.

GitHub consente tre opzioni quando una o più esecuzioni di controllo hanno esito negativo per una richiesta pull/commit. È possibile scegliere di "rieseguire" il singolo controllo, eseguire di nuovo tutti i controlli non riusciti in tale richiesta pull/commit oppure eseguire di nuovo tutti i controlli, indipendentemente dal fatto che abbiano avuto esito positivo o meno.

Facendo clic sul collegamento "Riesegui" accanto al nome verifica esecuzione, Azure Pipelines ritenta l'esecuzione che ha generato l'esecuzione. L'esecuzione risultante avrà lo stesso numero di esecuzione e userà la stessa versione del codice sorgente, della configurazione e del file YAML della build iniziale. Solo i processi non riusciti nell'esecuzione iniziale e tutti i processi downstream dipendenti verranno eseguiti di nuovo. Facendo clic sul collegamento "Riesegui tutti i controlli non riusciti" avrà lo stesso effetto. Si tratta dello stesso comportamento di fare clic su "Riprova esecuzione" nell'interfaccia utente di Azure Pipelines. Facendo clic su "Riesegui tutti i controlli" si verificherà una nuova esecuzione, con un nuovo numero di esecuzione e verranno prelevate le modifiche nel file di configurazione o YAML.

Limiti

• Per ottenere prestazioni ottimali, è consigliabile usare un massimo di 50 pipeline in un singolo repository. Per prestazioni accettabili, è consigliabile usare un massimo di 100 pipeline in un singolo repository. Il tempo necessario per elaborare un push in un repository aumenta con il numero di pipeline in tale repository. Ogni volta che viene eseguito il push in un repository, Azure Pipelines deve caricare tutte le pipeline YAML in tale repository per determinare se una di esse deve essere eseguita e il caricamento di ogni pipeline comporta una riduzione delle prestazioni. Oltre ai problemi di prestazioni, la presenza di troppe pipeline in un singolo repository può causare limitazioni sul lato di GitHub, perché Azure Pipelines può effettuare troppe richieste in un breve periodo di tempo.

• L'uso di estende e include modelli in una pipeline influisce sulla frequenza con cui Azure Pipelines effettua richieste api GitHub e può causare limitazioni sul lato di GitHub. Prima di eseguire una pipeline, Azure Pipelines deve generare il codice YAML completo, quindi deve recuperare tutti i file modello.

• Azure Pipelines carica un massimo di 2000 rami da un repository in elenchi a discesa nel portale di Azure DevOps, ad esempio nella finestra Selezionare un ramo per il ramo predefinito per le compilazioni manuali e pianificate oppure quando si sceglie un ramo quando si esegue manualmente una pipeline.

  Se non viene visualizzato il ramo desiderato nell'elenco, digitare manualmente il nome del ramo desiderato nel campo Default branch for manual and scheduled build (Ramo predefinito per compilazioni manuali e pianificate).

  Se si fa clic sui puntini di sospensione e si apre la finestra di dialogo Seleziona un ramo e la si chiude senza scegliere un ramo valido dall'elenco a discesa, è possibile che venga visualizzato un messaggio di attenzione Alcune impostazioni e che sia necessario un messaggio Questa impostazione è obbligatoria sotto Il ramo predefinito per le compilazioni manuali e pianificate. Per aggirare questo messaggio, riaprire la pipeline e immettere il nome direttamente nel ramo predefinito per il campo Compilazioni manuali e pianificate.

Domande frequenti

I problemi relativi all'integrazione di GitHub rientrano nelle categorie seguenti:

• Tipi di connessione: non si è certi del tipo di connessione usato per connettere la pipeline a GitHub.
• Trigger con errori: la pipeline non viene attivata quando si esegue il push di un aggiornamento nel 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.
• Aggiornamenti dello stato mancanti: le richieste pull di GitHub sono bloccate perché Azure Pipelines non ha inviato un aggiornamento dello stato.

Tipi di connessioni

Per risolvere i problemi relativi ai trigger, come si conosce il tipo di connessione GitHub in uso per la pipeline?

La risoluzione dei problemi relativi ai trigger dipende molto dal tipo di connessione GitHub usata nella pipeline. Esistono due modi per determinare il tipo di connessione, da GitHub e da Azure Pipelines.

• Da GitHub: se un repository è configurato per l'uso dell'app GitHub, gli stati nelle richieste pull e i commit saranno Verifica esecuzioni. Se il repository ha Azure Pipelines configurato con connessioni OAuth o PAT, gli stati saranno lo stile di stato "vecchio". Un modo rapido per determinare se gli stati sono Controlla esecuzioni o stati semplici consiste nell'esaminare la scheda "conversazione" in una richiesta pull di GitHub.

  • Se il collegamento "Dettagli" reindirizza alla scheda Controlli, si tratta di un'esecuzione verifica e il repository usa l'app.
  • Se il collegamento "Dettagli" reindirizza alla pipeline di Azure DevOps, lo stato è uno stato "vecchio" e il repository non usa l'app.

• Da Azure Pipelines: è anche possibile determinare il tipo di connessione esaminando la pipeline nell'interfaccia utente di Azure Pipelines. Aprire l'editor per la pipeline. Selezionare Trigger per aprire l'editor classico per la pipeline. Selezionare quindi la scheda YAML e quindi il passaggio Recupera origini . Si noterà un banner Autorizzato tramite connessione: indica la connessione al servizio usata per integrare la pipeline con GitHub. Il nome della connessione al servizio è un collegamento ipertestuale. Selezionarlo per passare alle proprietà di connessione del servizio. Le proprietà della connessione al servizio indicherà il tipo di connessione in uso:

  • L'app Azure Pipelines indica la connessione all'app GitHub
  • oauth indica la connessione OAuth
  • personalaccesstoken indica l'autenticazione PAT

Ricerca per categorie cambiare la pipeline per usare l'app GitHub anziché OAuth?

L'uso di un'app GitHub anziché una connessione OAuth o PAT è l'integrazione consigliata tra GitHub e Azure Pipelines. Per passare all'app GitHub, seguire questa procedura:

1. Passare qui e installare l'app nell'organizzazione GitHub del repository.
2. Durante l'installazione, si verrà reindirizzati ad Azure DevOps per scegliere un'organizzazione e un progetto Di Azure DevOps. Scegliere l'organizzazione e il progetto che contengono la pipeline di compilazione classica per cui si vuole usare l'app. Questa scelta associa l'installazione dell'app GitHub all'organizzazione Azure DevOps. Se si sceglie in modo errato, è possibile visitare questa pagina per disinstallare l'app GitHub dall'organizzazione GitHub e ricominciare.
3. Nella pagina successiva visualizzata non è necessario procedere con la creazione di una nuova pipeline.
4. Modificare la pipeline visitando la pagina Pipeline (ad esempio, https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build), selezionando la pipeline e facendo clic su Modifica.
5. Se si tratta di una pipeline YAML, selezionare il menu Trigger per aprire l'editor classico.
6. Selezionare il passaggio "Recupera origini" nella pipeline.
7. Sulla barra verde con il testo "Authorized using connection", selezionare "Change" (Modifica) e selezionare la connessione all'app GitHub con lo stesso nome dell'organizzazione GitHub in cui è stata installata l'app.
8. Sulla barra degli strumenti selezionare "Salva e accodamento" e quindi "Salva e accodamento". Selezionare il collegamento all'esecuzione della pipeline in coda per assicurarsi che abbia esito positivo.
9. Creare (o chiudere e riaprire) una richiesta pull nel repository GitHub per verificare che una compilazione sia stata accodata correttamente nella sezione "Controlli".

Perché non viene visualizzato un repository GitHub da scegliere in Azure Pipelines?

A seconda del tipo di autenticazione e della proprietà del repository, sono necessarie autorizzazioni specifiche.

• Se si usa l'app GitHub, vedere Autenticazione dell'app GitHub.
• Se si usa OAuth, vedere Autenticazione OAuth.
• Se si usano i token di accesso personale, vedere Autenticazione del token di accesso personale .

Quando si seleziona un repository durante la creazione della pipeline, viene visualizzato un errore "Il repository {nome repository} è in uso con l'app GitHub di Azure Pipelines in un'altra organizzazione di Azure DevOps".

Ciò significa che il repository è già associato a una pipeline in un'organizzazione diversa. Gli eventi CI e PR di questo repository non funzioneranno perché verranno recapitati all'altra organizzazione. Ecco i passaggi da eseguire per rimuovere il mapping all'altra organizzazione prima di procedere alla creazione di una pipeline.

1. Aprire una richiesta pull nel repository GitHub e impostare il commento /azp where. In questo modo viene segnalato all'organizzazione azure DevOps a cui è stato eseguito il mapping del repository.

2. Per modificare il mapping, disinstallare l'app dall'organizzazione GitHub e reinstallarla. Durante la reinstallazione, assicurarsi di selezionare l'organizzazione corretta quando si viene reindirizzati ad Azure DevOps.

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:

• I trigger di integrazione continua o richiesta pull YAML vengono sottoposti a override dalle impostazioni della pipeline nell'interfaccia utente? Durante la modifica della pipeline, scegliere ... e quindi Trigger.

  

  Controllare l'impostazione Esegui l'override del trigger YAML da qui per i tipi di trigger (integrazione continua o convalida della richiesta pull) disponibili per il repository.

  

• Si usa la connessione all'app GitHub per connettere la pipeline a GitHub? Vedere Tipi di connessione per determinare il tipo di connessione disponibile. Se si usa una connessione all'app GitHub, seguire questa procedura:

  • Il mapping è configurato correttamente tra GitHub e Azure DevOps? Aprire una richiesta pull nel repository GitHub e impostare il commento /azp where. In questo modo viene segnalato all'organizzazione azure DevOps a cui è stato eseguito il mapping del repository.

    • Se nessuna organizzazione è configurata per compilare questo repository usando l'app, passare a https://github.com/<org_name>/<repo_name>/settings/installations e completare la configurazione dell'app.

    • Se viene segnalata un'altra organizzazione di Azure DevOps, un utente ha già stabilito una pipeline per questo repository in un'organizzazione diversa. Attualmente è presente la limitazione che è possibile eseguire il mapping di un repository GitHub solo a una singola organizzazione DevOps. Solo le pipeline nella prima organizzazione di Azure DevOps possono essere attivate automaticamente. Per modificare il mapping, disinstallare l'app dall'organizzazione GitHub e reinstallarla. Durante la reinstallazione, assicurarsi di selezionare l'organizzazione corretta quando si viene reindirizzati ad Azure DevOps.

• Si usa OAuth o PAT per connettere la pipeline a GitHub? Vedere Tipi di connessione per determinare il tipo di connessione disponibile. Se si usa una connessione GitHub, seguire questa procedura:

  1. Le connessioni OAuth e PAT si basano sui webhook per comunicare gli aggiornamenti ad Azure Pipelines. In GitHub passare alle impostazioni per il repository e quindi a Webhook. Verificare che i webhook esistano. In genere dovrebbero essere visualizzati tre webhook: push, pull_request e issue_comment. In caso contrario, è necessario ricreare la connessione al servizio e aggiornare la pipeline per usare la nuova connessione al servizio.

  2. Selezionare ognuno dei webhook in GitHub e verificare che il payload corrispondente al commit dell'utente esista e che sia stato inviato correttamente ad Azure DevOps. È possibile che venga visualizzato un errore qui se non è stato possibile comunicare l'evento ad Azure DevOps.

• Il traffico da Azure DevOps potrebbe essere limitato da GitHub. Quando Azure Pipelines riceve una notifica da GitHub, prova a contattare GitHub e recuperare altre informazioni sul repository e sul file YAML. Se si dispone di un repository con un numero elevato di aggiornamenti e richieste pull, questa chiamata potrebbe non riuscire a causa di tale limitazione. In questo caso, verificare se è possibile ridurre la frequenza delle compilazioni usando filtri di percorso/ramo più rigidi o in batch.

• 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, quindi seguire 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 un ritardo verificando se il problema è specifico di una singola pipeline o è comune a tutte le pipeline o i 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. Ecco alcuni motivi per cui può verificarsi un ritardo:

  • Si è verificato 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.
  • Il repository contiene troppe pipeline YAML. Per ottenere prestazioni ottimali, è consigliabile usare un massimo di 50 pipeline in un singolo repository. Per prestazioni accettabili, è consigliabile usare un massimo di 100 pipeline in un singolo repository. Più pipeline sono presenti, più lenta è l'elaborazione di un push in tale repository. Ogni volta che viene eseguito il push in un repository, Azure Pipelines deve caricare tutte le pipeline YAML in tale repository per determinare se è necessario eseguirle e ogni nuova pipeline comporta una riduzione delle prestazioni.

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.

Checkout non riuscito

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

remote: Repository not found.
fatal: repository <repo> not found

Questo problema potrebbe essere causato da un'interruzione di GitHub. Provare ad accedere al repository in GitHub e assicurarsi di essere in grado di farlo.

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.

Aggiornamenti dello stato mancanti

La richiesta pull in GitHub è bloccata perché Azure Pipelines non ha aggiornato lo stato.

Potrebbe trattarsi di un errore temporaneo che ha causato la mancata comunicazione di Azure DevOps con GitHub. Ripetere l'archiviazione in GitHub se si usa l'app GitHub. In alternativa, eseguire un aggiornamento semplice della richiesta pull per verificare se il problema può essere risolto.

Articoli correlati

• Trigger pianificati
• Trigger di completamento della pipeline