Compilare repository GitHub Enterprise Server

Servizi di Azure DevOps

È possibile integrare GitHub Enterprise Server locale con Azure Pipelines. Il server locale potrebbe essere esposto a Internet o potrebbe non essere.

Se GitHub Enterprise Server è raggiungibile dai server che eseguono il servizio Azure Pipelines, allora:

• è possibile configurare le pipeline di compilazione e YAML classiche
• è possibile configurare trigger ci, richieste pull e trigger pianificati

Se GitHub Enterprise Server non è raggiungibile dai server che eseguono il servizio Azure Pipelines, allora:

• è possibile configurare solo le pipeline di compilazione classiche
• è possibile avviare solo compilazioni manuali o pianificate
• non è possibile configurare pipeline YAML
• non è possibile configurare trigger di integrazione continua o pull per le pipeline di compilazione classiche

Se il server locale è raggiungibile dagli agenti ospitati da Microsoft, è possibile usarli per eseguire le pipeline. In caso contrario, è necessario configurare agenti self-hosted in grado di accedere al server locale e recuperare il codice.

Raggiungibile da Azure Pipelines

La prima cosa da verificare è se GitHub Enterprise Server è raggiungibile dal servizio Azure Pipelines.

1. Nell'interfaccia utente di Azure DevOps passare alle impostazioni del progetto e selezionare Connessioni al servizio in Pipeline.
2. Selezionare Nuova connessione al servizio e scegliere GitHub Enterprise Server come tipo di connessione.
3. Immettere le informazioni necessarie per creare una connessione a GitHub Enterprise Server.
4. Selezionare Verifica nel pannello di connessione del servizio.

Se la verifica viene superata, i server che eseguono il servizio Azure Pipelines sono in grado di raggiungere gitHub Enterprise Server locale. È possibile procedere e configurare la connessione. È quindi possibile usare questa connessione al servizio durante la creazione di una pipeline YAML o di compilazione classica. È anche possibile configurare trigger CI e PR per la pipeline. La maggior parte delle funzionalità di Azure Pipelines che funzionano con GitHub funziona anche con GitHub Enterprise Server. Esaminare la documentazione per GitHub per comprendere queste funzionalità. Ecco alcune differenze:

• L'integrazione tra GitHub e Azure Pipelines è resa più semplice tramite un'app Azure Pipelines nel marketplace GitHub. Questa app consente di configurare un'integrazione senza dover basarsi sul token OAuth di un determinato utente. Non è disponibile un'app simile che funziona con GitHub Enterprise Server. È quindi necessario usare un token di accesso personale, un nome utente e una password o OAuth per configurare la connessione tra Azure Pipelines e il server GitHub Enterprise.
• Azure Pipelines supporta diverse funzionalità di sicurezza di GitHub per convalidare i contributi dai fork esterni. Ad esempio, i segreti archiviati in una pipeline non vengono resi disponibili per un processo in esecuzione. Queste protezioni non sono disponibili quando si lavora con il server GitHub Enterprise.
• I trigger di commento non sono disponibili con gitHub Enterprise Server. Non è possibile usare commenti in una richiesta pull del repository del server GitHub Enterprise per attivare una pipeline.
• I controlli GitHub non sono disponibili nel server GitHub Enterprise. Tutti gli aggiornamenti dello stato sono tramite gli stati di base.

Non raggiungibile da Azure Pipelines

Quando la verifica di una connessione GitHub Enterprise Server come illustrato nella sezione precedente ha esito negativo, Azure Pipelines non può comunicare con il server. Questo è probabilmente causato dalla configurazione della rete aziendale. Ad esempio, un firewall nella rete potrebbe impedire al traffico esterno di raggiungere i server. In questo caso sono disponibili due opzioni:

• Collaborare con il reparto IT per aprire un percorso di rete tra Azure Pipelines e GitHub Enterprise Server. Ad esempio, è possibile aggiungere eccezioni alle regole del firewall per consentire il flusso del traffico da Azure Pipelines. Vedere la sezione sugli indirizzi IP di Azure DevOps per vedere gli indirizzi IP che è necessario consentire. È inoltre necessario disporre di una voce DNS pubblica per GitHub Enterprise Server in modo che Azure Pipelines possa risolvere il nome di dominio completo del server in un indirizzo IP. Con tutte queste modifiche, provare a creare e verificare una connessione GitHub Enterprise Server in Azure Pipelines.

• Anziché usare una connessione GitHub Enterprise Server, è possibile usare un'altra connessione Git . Assicurarsi di deselezionare l'opzione Tenta di accedere a questo server Git da Azure Pipelines. Con questo tipo di connessione, è possibile configurare solo una pipeline di compilazione classica. I trigger ci e pr non funzioneranno in questa configurazione. È possibile avviare solo esecuzioni di pipeline manuali o pianificate.

Raggiungibile dagli agenti ospitati da Microsoft

Un'altra decisione da prendere è se usare agenti ospitati da Microsoft o agenti self-hosted per eseguire le pipeline. Questo spesso dipende dal fatto che gli agenti ospitati da Microsoft possano raggiungere il server. Per verificare se possono, creare una pipeline semplice per usare gli agenti ospitati da Microsoft e assicurarsi di aggiungere un passaggio per controllare il codice sorgente dal server. Se questa operazione viene superata, è possibile continuare a usare gli agenti ospitati da Microsoft.

Non raggiungibile dagli agenti ospitati da Microsoft

Se la pipeline di test semplice indicata nella sezione precedente ha esito negativo con l'errore TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting, GitHub Enterprise Server non è raggiungibile dagli agenti ospitati da Microsoft. Questo problema è probabilmente causato da un firewall che blocca il traffico da questi server. In questo caso sono disponibili due opzioni:

• Collaborare con il reparto IT per aprire un percorso di rete tra gli agenti ospitati da Microsoft e GitHub Enterprise Server. Vedere la sezione relativa alla rete negli agenti ospitati da Microsoft.

• Passare all'uso di agenti self-hosted o agenti del set di scalabilità. Questi agenti possono essere configurati all'interno della rete e quindi avranno accesso a GitHub Enterprise Server. Questi agenti richiedono solo connessioni in uscita ad Azure Pipelines. Non è necessario aprire un firewall per le connessioni in ingresso. Assicurarsi che il nome del server specificato durante la creazione della connessione GitHub Enterprise Server sia risolvibile dagli agenti self-hosted.

Indirizzi IP di Azure DevOps

Azure Pipelines invia richieste a GitHub Enterprise Server a:

• Eseguire una query per un elenco di repository durante la creazione della pipeline (pipeline CLASSICHE e YAML)
• Cercare file YAML esistenti durante la creazione della pipeline (pipeline YAML)
• Archiviare file YAML (pipeline YAML)
• Registrare un webhook durante la creazione della pipeline (pipeline YAML e classiche)
• Presentare un editor per i file YAML (pipeline YAML)
• Risolvere i modelli ed espandere i file YAML prima dell'esecuzione (pipeline YAML)
• Controllare se sono state apportate modifiche dall'ultima esecuzione pianificata (pipeline CLASSICHE e YAML)
• Recuperare i dettagli sul commit più recente e visualizzarli nell'interfaccia utente (pipeline CLASSICHE e YAML)

È possibile osservare che le pipeline YAML richiedono fondamentalmente la comunicazione tra Azure Pipelines e GitHub Enterprise Server. Di conseguenza, non è possibile configurare una pipeline YAML se GitHub Enterprise Server non è visibile ad Azure Pipelines.

Quando si usa Altre connessioni Git per configurare una pipeline classica, disabilitare la comunicazione tra il servizio Azure Pipelines e GitHub Enterprise Server e usare agenti self-hosted per compilare il codice, si otterrà un'esperienza danneggiata:

• Sarà necessario digitare manualmente il nome del repository durante la creazione della pipeline
• Non è possibile usare trigger ci o pr perché Azure Pipelines non può registrare un webhook in GitHub Enterprise Server
• Non è possibile usare trigger pianificati con l'opzione per la compilazione solo quando sono presenti modifiche
• Non è possibile visualizzare informazioni sul commit più recente nell'interfaccia utente

Se si vogliono configurare pipeline YAML o se si vuole migliorare l'esperienza con le pipeline classiche, è importante abilitare la comunicazione da Azure Pipelines a GitHub Enterprise Server.

Per consentire al traffico da Azure DevOps di raggiungere GitHub Enterprise Server, aggiungere gli indirizzi IP o i tag di servizio specificati nelle connessioni in ingresso all'elenco di indirizzi consentiti del firewall. Se si usa ExpressRoute, assicurarsi di includere anche gli intervalli IP di ExpressRoute nell'elenco di indirizzi consentiti del firewall.

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 Enterprise rientrano nelle categorie seguenti:

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

Trigger con errori

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

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

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

  

• I webhook vengono usati per comunicare gli aggiornamenti da GitHub Enterprise ad Azure Pipelines. In GitHub Enterprise passare alle impostazioni per il repository e quindi a Webhook. Verificare che i webhook esistano. In genere dovrebbero essere visualizzati due webhook: push, pull_request. In caso contrario, è necessario ricreare la connessione al servizio e aggiornare la pipeline per usare la nuova connessione al servizio.

• Selezionare ognuno dei webhook in GitHub Enterprise 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.

• Quando Azure Pipelines riceve una notifica da GitHub, prova a contattare GitHub e recuperare altre informazioni sul repository e sul file YAML. Se GitHub Enterprise Server si trova dietro un firewall, questo traffico potrebbe non raggiungere il server. Vedere Indirizzi IP di Azure DevOps e verificare di aver concesso eccezioni a tutti gli indirizzi IP necessari. Questi indirizzi IP potrebbero essere stati modificati dopo aver originariamente configurato le regole di eccezione.

• 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.
  • L'istanza di GitHub Enterprise Server potrebbe essere sottoposta a provisioning, rallentando l'elaborazione delle richieste da Azure Pipelines. Altre informazioni sulle considerazioni sull'hardware per GitHub Enterprise Server.

Checkout non riuscito

Si usano agenti ospitati da Microsoft? In questo caso, questi agenti potrebbero non essere in grado di raggiungere GitHub Enterprise Server. Per altre informazioni, vedere Non raggiungibile dagli agenti ospitati da Microsoft.

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.