Creazione di repository da GitHub Enterprise

1a generazione 2a generazione

Cloud Build consente di creare trigger su un'istanza GitHub Enterprise. Questa pagina spiega come utilizzare i trigger GitHub Enterprise per richiamare le build in risposta a commit o richieste di pull da un repository GitHub Enterprise.

Scopri di più sui trigger di Cloud Build e sui repository Cloud Build.

Prima di iniziare

• Abilita le API Cloud Build and Secret Manager.

  Abilita le API

• Segui le istruzioni per connettere un host GitHub Enterprise.
• Segui le istruzioni per connettere un repository GitHub Enterprise.

Creazione di un trigger GitHub Enterprise

Questa sezione spiega come creare un trigger e collegarlo alla tua installazione GitHub Enterprise. Se vuoi utilizzare i trigger GitHub Enterprise in una rete privata, consulta Creazione di repository da GitHub Enterprise in una rete privata per ulteriori istruzioni.

Nota: i trigger manuali e i trigger Pub/Sub non possono creare repository GitHub Enterprise tramite l'integrazione di Cloud Build. Per clonare e creare repository tramite GitHub Enterprise, consulta Creazione e gestione dei trigger di build per informazioni su come specificare una configurazione di build in linea.

Console

Per creare trigger GitHub Enterprise utilizzando la console Google Cloud:

1. Apri la pagina Attivatori nella console Google Cloud.

   Apri la pagina Attivatori

2. Seleziona il progetto dal menu a discesa del selettore di progetti nella parte superiore della pagina.

3. Fai clic su Apri.

4. Fai clic su Crea trigger.

5. Inserisci le seguenti impostazioni di attivazione:

   • Nome: inserisci un nome per l'attivatore.

   • Regione: seleziona la regione per l'attivatore.

     • Se il file di configurazione della build associato al trigger specifica un pool privato, Cloud Build utilizza il pool privato per eseguire la build. In questo caso, la regione specificata nel trigger deve corrispondere a quella in cui hai creato il pool privato.
     • Se il file di configurazione della build associato al trigger non specifica un pool privato, Cloud Build utilizza il pool predefinito per eseguire la build nella stessa regione del trigger.

   • (Facoltativo) Descrizione: inserisci una descrizione per l'attivatore.

   • Evento: seleziona l'evento del repository per richiamare il trigger.

     • Push al ramo: imposta il trigger per avviare una build sui commit in un ramo specifico.

     • Esegui il push del nuovo tag: imposta l'attivatore in modo che avvii una build sui commit che contengono un determinato tag.

     • Richiesta di pull: imposta il trigger per avviare una build sui commit in una richiesta di pull.

       Nota: l'esecuzione delle build avviate da un trigger della richiesta di pull dell'app GitHub viene annullata alla chiusura della richiesta di pull associata alla build. L'esecuzione di build e build che non sono ancora state avviate non verrà annullata durante l'unione di una richiesta di pull.

   • Origine: seleziona Seconda generazione come origine.

     Nota: la regione del repository deve corrispondere a quella del trigger.

     • Repository: dall'elenco dei repository disponibili, seleziona il repository desiderato. Per connettere un nuovo repository, vedi Connettersi a un repository GitHub Enterprise.

     • Ramo o Tag: specifica un'espressione regolare con il valore del ramo o del tag da associare. Per informazioni sulla sintassi accettabile delle espressioni regolari, consulta la sezione sintassi RE2.

     • Controllo dei commenti: se hai selezionato Richiesta di pull (solo app GitHub) come Evento, scegli una delle seguenti opzioni per controllare se una build verrà eseguita automaticamente dal trigger:

       Avviso: qualsiasi utente con accesso in lettura al repository può inviare una richiesta di pull, che potrebbe eseguire una build che include modifiche al codice sorgente nella richiesta di pull. Per disabilitare questo comportamento, ti consigliamo di utilizzare le approvazioni manuali al fine di limitare le build quando esegui richieste di pull sui repository pubblici. Per ulteriori informazioni sui privilegi dei trigger in fase di build, consulta Trigger di build e account di servizio Cloud Build.

       • Obbligatorio tranne per proprietari e collaboratori: quando una richiesta di pull viene creata o aggiornata da un proprietario o un collaboratore del repository, le build vengono eseguite automaticamente dall'attivatore. Se un collaboratore esterno avvia l'azione, le build verranno eseguite solo dopo che un proprietario o un collaboratore commenta /gcbrun nella richiesta di pull.

       • Obbligatorio: quando una richiesta di pull viene creata o aggiornata da un proprietario o un collaboratore del repository con /gcbrun nella descrizione o nel commento della richiesta di pull, l'attivatore esegue automaticamente le build. Quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build vengono eseguite solo dopo che un proprietario o un collaboratore commenta /gcbrun nella richiesta di pull.

       • Non obbligatoria: quando un collaboratore crea o aggiorna una richiesta di pull, le build vengono eseguite automaticamente dagli attivatori.

   • File inclusi (facoltativo): le modifiche che interessano almeno uno di questi file richiamano una build.

   • File ignorati (facoltativo): le modifiche che interessano solo i file ignorati non richiamano una build.

     Nota: i campi File inclusi e File ignorati possono essere specificati solo se hai selezionato Invia a un ramo come Evento. Per saperne di più su File inclusi e File ignorati, consulta la scheda Console in Creazione di un trigger di build.

   • Configurazione: seleziona il file di configurazione della build che si trova nel repository remoto o crea un file di configurazione di compilazione incorporato da utilizzare per la build.

     • Tipo: seleziona il tipo di configurazione da utilizzare per la build.
       • Rilevato automaticamente: Cloud Build rileva automaticamente il tipo di configurazione se nel repository è presente un valore cloudbuild.yaml o Dockerfile.
       • File di configurazione di Cloud Build (yaml o json): utilizza un file di configurazione di compilazione per la tua configurazione.
       • Dockerfile: utilizza un Dockerfile per la configurazione.
       • Buildpack: utilizza buildpacks per la configurazione.

     • Posizione: specifica la località per la configurazione.

       • Repository: se il file di configurazione si trova nel repository remoto, fornisci la posizione del file di configurazione della build o della directory Dockerfile, oltre a un nome per l'immagine risultante. Se la configurazione è Dockerfile, puoi specificare facoltativamente un timeout per la build. Dopo aver fornito Dockerfile e il nome dell'immagine, vedrai un'anteprima del comando docker build che verrà eseguita dalla build.
       • In linea: se hai selezionato File di configurazione di Cloud Build (yaml o json) come opzione di configurazione, puoi specificare la configurazione di compilazione in linea. Fai clic su Apri editor per scrivere il file di configurazione della build nella console Google Cloud utilizzando la sintassi YAML o JSON. Fai clic su Fine per salvare la configurazione della build.
       Nota: il supporto per la configurazione della build in linea non è disponibile per Dockerfile.

   • Variabili di sostituzione (facoltativo): se hai selezionato il file di configurazione di Cloud Build come opzione di configurazione della build, puoi scegliere di definire variabili di sostituzione specifiche del trigger utilizzando questo campo. Ad esempio, supponiamo che tu stia creando più trigger in cui ogni trigger esegue il deployment della tua app in un ambiente specifico. Puoi specificare che il deployment dell'app è stato eseguito in un ambiente nel file di configurazione della build, quindi utilizzare questo campo per definire le variabili di sostituzione che specificano in quale ambiente deve essere eseguito il deployment di questo trigger. Per informazioni su come specificare i valori di sostituzione nei file di configurazione della build, consulta Sostituzione dei valori delle variabili.

   • Log di build (facoltativo): seleziona la casella per inviare i log di build a GitHub. Per informazioni su come visualizzare i log di build, vedi Visualizzazione dei log di build.

   • Account di servizio: seleziona l'account di servizio da utilizzare quando richiami il trigger. Se non selezioni un account di servizio, viene utilizzato l'account di servizio Cloud Build predefinito.

     Nota: per le build eseguite dai trigger verrà utilizzato solo l'account di servizio specificato nel trigger. Se hai specificato un account di servizio nella configurazione della build, questo verrà ignorato durante l'esecuzione della build quando utilizzi i trigger.

6. Fai clic su Crea per salvare il trigger di build.

Per creare trigger GitHub utilizzando i comandi gcloud, consulta i comandi gcloud per creare un trigger di build.

gcloud

Per creare trigger GitHub Enterprise utilizzando i comandi gcloud, esegui questo comando:

gcloud builds triggers create github \
  --name=TRIGGER_NAME \
  --repository=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/repositories/REPO_NAME \
  --branch-pattern=BRANCH_PATTERN # or --tag-pattern=TAG_PATTERN \
  --build-config=BUILD_CONFIG_FILE \
  --region=REGION

Dove:

• TRIGGER_NAME è il nome dell'attivatore.
• PROJECT_ID è l'ID del tuo progetto Google Cloud.
• REGION è la regione del trigger.
• CONNECTION_NAME è il nome della tua connessione GitHub Enterprise.
• REPO_NAME è il nome del tuo repository
• BRANCH_PATTERN è il nome del ramo nel repository per richiamare la build.
• TAG_PATTERN è il nome del tag nel repository per richiamare la build.
• BUILD_CONFIG_FILE è il percorso del file di configurazione della build.

Condivisione dei dati

I dati inviati a GitHub Enterprise da Cloud Build consentono di identificare i trigger in base al nome e visualizzare i risultati della build su GitHub Enterprise.

I seguenti dati sono attualmente condivisi tra Cloud Build e GitHub Enterprise:

• ID progetto Cloud
• Nome trigger
• Log di build

Nota: i log di build vengono condivisi solo se configuri il trigger per inviare i log di build.

Se hai creato trigger prima di agosto 2020, la condivisione dei dati potrebbe non essere abilitata per il progetto. Puoi abilitare la condivisione dei dati per tutti i trigger di GitHub Enterprise nel tuo progetto facendo clic su Abilita nella scheda Condivisione dei dati di Cloud Build.

Se hai abilitato controlli dello stato obbligatori per un repository GitHub Enterprise, l'attivazione della condivisione dei dati potrebbe interrompere temporaneamente i controlli dello stato. Puoi modificare le configurazioni dei controlli dello stato per cercare il nome del trigger:

• Disabilitazione di eventuali controlli obbligatori specifici di Cloud Build nel repository GitHub Enterprise
• Assicurarsi che la condivisione dei dati sia abilitata in Cloud Build
• Esecuzione di una nuova build in Cloud Build che pubblichi stati nel tuo repository
• Riattivazione dei controlli di stato obbligatori, selezione del nome del trigger

Nota: l'abilitazione della condivisione dei dati per un progetto è irreversibile.

Passaggi successivi

• Scopri come creare e gestire gli attivatori.
• Scopri come creare repository da GitHub Enterprise in una rete privata.
• Scopri come eseguire deployment blu/verde su Compute Engine.