Compilare repository GitHub

di Azure DevOps Services

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 i passaggi descritti 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 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 in base all'organizzazione GitHub e al repository compilate, 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. Per esempio:

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

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.

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.

Se il repository GitHub concede l'autorizzazione ai team, è possibile creare team corrispondenti nella sezione Teams 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... aggiungere un utente, un team o un gruppo specifico e personalizzarne le autorizzazioni per la pipeline.

Accesso ai repository GitHub

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.

Autenticazione dell'app GitHub

L'app GitHub di Azure Pipelines è il consigliato tipo di autenticazione 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. Tuttavia, se l'app è installata per tutti i repository, il token usato dall'applicazione avrà accesso a tutti i repository, inclusi quelli privati. Per motivi di sicurezza, è consigliabile separare i repository privati e pubblici a livello di organizzazione. Ciò significa avere un'organizzazione dedicata solo per i progetti pubblici senza repository privati. Se, per qualche motivo, è necessario disporre di repository pubblici e privati nella stessa organizzazione, anziché usare l'accesso per tutti i repository, selezionare in modo esplicito i repository a cui l'applicazione deve avere accesso. Questo richiede più lavoro per gli amministratori, ma garantisce una migliore gestione della sicurezza.

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:

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 Autorizzare ad 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 Pipeline > Connessioni al servizio > Nuova connessione al servizio > GitHub > Autorizza. 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 Pipeline > Connessioni al servizio > Nuova connessione al servizio > GitHub > Autorizza. L'altra persona deve concedere ad Azure Pipelines l'accesso ai 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 Pipeline > Connessioni al servizio > Nuova connessione al servizio > GitHub > Autorizza. Concedere ad Azure Pipelines l'accesso 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 Pipeline > Connessioni al servizio > Nuova connessione al servizio > GitHub > Autorizza. Il proprietario dell'organizzazione deve concedere ad Azure Pipelines l'accesso 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 aver autorizzato Azure Pipelines a usare OAuth, per revocarlo in un secondo momento e impedire un ulteriore uso, visitare 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 sono effettivamente 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, visitare 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 l'autorizzazione di Azure Pipelines all'uso di un token di accesso personale, per eliminarlo in un secondo momento e impedire un ulteriore uso, visitare 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.

trigger:
- main
- releases/*

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

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

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

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

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

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

# A pipeline with no CI trigger
trigger: none

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] o [ci skip]
• skip-checks: true o skip-checks:true
• [skip azurepipelines] o [azurepipelines skip]
• [skip azpipelines] o [azpipelines skip]
• [skip azp] o [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 di sistema Build.Reason. 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, può essere necessario attivare una pipeline quando si esegue il push di un aggiornamento nella cartella docs 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 modelli con caratteri jolly consentono * di trovare la corrispondenza con zero o più caratteri e ? per 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 rispetto alla specifica del nome della directory da solo. È possibile non includere * al centro di un filtro di percorso e non 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.

pr:
- main
- releases/*

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

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

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

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

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

# no PR triggers
pr: none

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 con un trigger di richiesta pull nel ramo di destinazione della richiesta pull verranno eseguite nel commit di merge (il codice unito tra i rami di origine e di destinazione della richiesta pull), indipendentemente dal fatto che esistano commit push i cui messaggi o descrizioni contengono (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 configurazione di rami protetti nelle impostazioni del repository.

   Per il controllo dello stato, selezionare il nome della pipeline nell'elenco Stato controlli.

   

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 accedere. 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 di Project Build Service per accedere ai feed del pacchetto.

Contributi dai fork

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 Compilare richieste pull dai fork di questo repository casella di controllo.

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 della libreria di file protetti
  • Le variabili di compilazione contrassegnate segreto

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

Per altre informazioni, vedere Protezione del repository - Forks.

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

• 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 di Limitare la compilazione di richieste pull dai repository GitHub con fork impostazione è Disabilitare la compilazione di richieste pull dai repository con fork.

Quando si sceglie l'opzione pull 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 da repository con fork, non è possibile rendere queste compilazioni con le stesse autorizzazioni delle compilazioni normali e devono essere attivate da un commento di 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 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 hanno compilare in modo sicuro le richieste pull 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. Questa 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 ospitati 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 build 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 pullabilitare 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 in caso di 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 Solo sulle richieste pull dai membri non del team sia selezionata e la richiesta pull venga effettuata da un membro del team. Solo i proprietari e i collaboratori del repository con l'autorizzazione "Scrittura" 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:

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 .

Cassa

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.

Versione preferita di Git

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

Percorso di estrazione

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

Moduli secondari

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

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

• Non autenticato: un 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. Per 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 Access 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 moduli secondari checkout . 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 di 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:. Successivamente, codifica 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.

Tag di sincronizzazione

Il passaggio di estrazione usa l'opzione --tags durante il recupero del 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 proprietà e nell'interfaccia utente configurando l'impostazione tag di sincronizzazione .

steps:
- checkout: self
  fetchTags: true

Comportamento predefinito

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

Recupero superficiale

È possibile limitare il tempo di download nella cronologia. In effetti, ciò 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.

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

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.

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.

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

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.

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

git clean -ffdx
git reset --hard HEAD

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

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.

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 possono essere definiti 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, alla compilazione completata viene aggiunto automaticamente un elemento con il riferimento Git refs/tags/{tag}. 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 sono disponibili 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 pat o connessioni OAuth GitHub, 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 Azure Pipelines GitHub, 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 Dei controlli di GitHub è 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.

Limitazioni

• 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 includere 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 impostazione o 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 ramo predefinito per le compilazioni manuali e pianificate campo.

  Se si fa clic sui puntini di sospensione e si apre il finestra di dialogo Selezionare un ramo e chiuderlo senza scegliere un ramo valido dall'elenco a discesa, è possibile che venga visualizzato un messaggio di Alcune impostazioni richiedono attenzione e un messaggio Questa impostazione è necessaria messaggio seguente Ramo predefinito per compilazioni manuali e pianificate. Per aggirare questo messaggio, riaprire la pipeline e immettere il nome direttamente nel campo ramo predefinito per le compilazioni manuali e pianificate campo.

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 al repository.
• checkout non riuscito: Pipeline personale viene attivata, ma ha esito negativo nel passaggio di estrazione.
• versione errata: Esecuzioni della pipeline personale, ma usa una versione imprevista dell'origine/YAML.
• Aggiornamenti dello stato mancanti: richieste pull GitHub personali sono bloccate perché Azure Pipelines non ha inviato un aggiornamento dello stato.

Tipi di connessione

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 scheda YAML e quindi il passaggio Ottenere origini. Si noterà un banner Connessione autorizzata tramite: che 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:

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

Come si passa alla 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 da capo.
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 (PAT).

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 sottoposti a override dalle impostazioni della pipeline nell'interfaccia utente? Durante la modifica della pipeline, scegliere ... e quindi Trigger.

  

  Controllare il Eseguire 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? Per determinare il tipo di connessione disponibile, vedere Tipi di connessione. 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? Per determinare il tipo di connessione disponibile, vedere Tipi di connessione. 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 farlo?

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 di .
3. Selezionare Eseguire l'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 è possibile correggerlo?

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