Creazione di repository da GitHub

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

I trigger di GitHub consentono di basarsi automaticamente sulle richieste di pull e di pull di Git e di visualizzare i risultati della build su GitHub e Google Cloud Console. Inoltre, i trigger di GitHub supportano tutte le funzionalità supportate dai trigger GitHub esistenti e utilizzano l'app GitHub di Cloud Build per configurare e eseguire l'autenticazione su GitHub.

Questa pagina spiega come creare trigger GitHub e creare su GitHub tramite l'app GitHub di Cloud Build.

Prima di iniziare

  • Attiva l'API Cloud Build.

    Abilita l'API

Creazione di un trigger GitHub

Console

Per creare i trigger GitHub utilizzando la console Google Cloud:

  1. Apri la pagina Trigger in Google Cloud Console.

    Apri la pagina Trigger

  2. Seleziona il progetto nel 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.

    • Area geografica: seleziona l'area geografica per l'attivatore.

      • Se selezioni globale come area geografica, Cloud Build utilizza il pool predefinito per eseguire la build.
      • Se selezioni un'area geografica non globale e il file di configurazione di compilazione 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 selezioni un'area geografica non globale e il file di configurazione di compilazione 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 di un nuovo tag: imposta il trigger per avviare una build sui commit che contengono un determinato tag.

      • Richiesta di pull (Cloud Source Repositories non supportato): imposta il trigger per avviare una build su commit su una richiesta di pull.

    • Origine: seleziona il repository e il ramo o il tag corrispondente da monitorare per gli eventi.

      • Repository: dall'elenco dei repository disponibili, seleziona il repository desiderato. Per connettere un nuovo repository, consulta la sezione Connessione di repository aggiuntivi.

      • Ramo o Tag: specifica un'espressione regolare con il valore del ramo o del tag da soddisfare. Per informazioni sulla sintassi accettabile delle espressioni regolari, consulta la 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:

        • Obbligatorio ad eccezione di proprietari e collaboratori: quando una richiesta di pull viene creata o aggiornata da un proprietario o da un collaboratore del repository, le build vengono eseguite automaticamente dal trigger. 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 collaboratore, le build vengono eseguite solo dopo che un proprietario o un collaboratore commenta /gcbrun sulla richiesta di pull. Le build vengono eseguite ogni volta che viene apportata una modifica a una richiesta di pull.

        • Non obbligatoria: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build vengono eseguite automaticamente dai trigger.

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

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

    • Configurazione: seleziona il file di configurazione della build situato nel repository remoto o crea un file di configurazione della build incorporato da utilizzare per la tua build.

      • Tipo: seleziona il tipo di configurazione da utilizzare per la build.
        • Rilevato automaticamente: Cloud Build rileva automaticamente il tipo di configurazione se nel tuo 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 configurazione.
        • Dockerfile: utilizza un Dockerfile per la configurazione.
        • Buildpack: utilizza i buildpack per la configurazione.
      • Località: specifica la posizione della configurazione.

        • Repository: se il file di configurazione si trova nel tuo repository remoto, fornisci la posizione del file di configurazione della build o la directory Dockerfile e un nome per l'immagine risultante. Se la configurazione è Dockerfile, puoi facoltativamente fornire un timeout per la build. Dopo aver fornito Dockerfile e il nome dell'immagine, vedrai un'anteprima del comando docker build che verrà eseguito.
        • In linea: se hai selezionato File di configurazione Cloud Build (yaml o json) come opzione di configurazione, puoi specificare la configurazione di build in linea. Fai clic su Apri editor per scrivere il file di configurazione della build in Google Cloud Console utilizzando la sintassi YAML o JSON. Fai clic su Fine per salvare la configurazione della build.
    • (Facoltativo) Variabili di sostituzione: se hai selezionato il file di configurazione thCloud Build come opzione di configurazione della build, puoi scegliere di definire le variabili di sostituzione specifiche del trigger utilizzando questo campo. Ad esempio, supponiamo che tu stia creando più trigger in cui ogni deployment esegue il deployment della tua app in un ambiente specifico. Puoi specificare il deployment dell'app 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 sulla specifica dei valori di sostituzione nei file di configurazione della build, consulta Sostituzione dei valori delle variabili.

    • (Facoltativo) Approvazione: seleziona la casella per richiedere l'approvazione prima di eseguire la build. Per scoprire di più sulle approvazioni, consulta Gate build on approval.

    • (Facoltativo) Log di build: seleziona la casella per inviare i log di build a GitHub. Per scoprire come visualizzare i log di build, vedi Visualizzare i log di build.

    • Account di servizio: seleziona l'account di servizio da utilizzare durante la chiamata al trigger. Se non selezioni un account di servizio, viene utilizzato l'account di servizio Cloud Build predefinito.

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

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

gcloud

Per creare i trigger GitHub utilizzando i comandi gcloud, esegui il comando seguente:

gcloud beta builds triggers create github \
    --repo-name=REPO_NAME \
    --repo-owner=REPO_OWNER \
    --branch-pattern=BRANCH_PATTERN \ # or --tag-pattern=TAG_PATTERN
    --build-config=BUILD_CONFIG_FILE \
    --include-logs-with-status

Dove:

  • REPO_NAME è il nome del tuo repository.
  • REPO_OWNER è il nome utente del proprietario del repository.
  • BRANCH_PATTERN è il nome del ramo nel tuo repository per richiamare la build.
  • TAG_PATTERN è il nome del tag nel tuo repository per richiamare la build.
  • BUILD_CONFIG_FILE è il percorso del file di configurazione della build.
  • [FACOLTATIVO] --include-logs-with-status è un flag che puoi specificare per visualizzare i log di build dei tuoi repository. Questo flag è supportato per le build da repository GitHub e GitHub Enterprise. Per informazioni su come visualizzare i log di build, vedi Visualizzare i log di build.

Creazione e visualizzazione delle modifiche

Per creare mediante i trigger GitHub, dovrai eseguire il push e il commit delle modifiche nel repository di origine connesso o configurare la build quando le richieste di pull sono eseguite. Dopo aver confermato le modifiche, Cloud Build creerà il tuo codice.

Per visualizzare le modifiche alla build su GitHub, vai alla scheda Controlli nel tuo repository.

Screenshot della scheda Conversazione

Vedrai che le modifiche sono state apportate da Cloud Build. Vedrai anche altri dettagli sulla build, come il tempo necessario per creare il codice e l'ID build.

Per visualizzare le modifiche alla build in Cloud Build, fai clic su Visualizza altri dettagli su Google Cloud Build. Nella pagina Dettagli build di Google Cloud Console si apre un punto in cui puoi visualizzare le informazioni sulla build come stato, log e passaggi di build.

Diversi tipi di trigger basati su GitHub

Se il codice sorgente è in GitHub, Cloud Build offre due modi per eseguire automaticamente le build. Questa sezione spiega i due trigger basati su GitHub e ne confronta le funzionalità.

  • Trigger legacy di GitHub: quando crei un trigger legacy di GitHub, Cloud Build esegue il mirroring del tuo repository GitHub in Cloud Source Repositories e utilizza il repository con mirroring per tutte le sue operazioni. Puoi creare e gestire i trigger GitHub utilizzando la console Google Cloud.

  • Trigger GitHub: questo tipo di trigger utilizza l'app GitHub di Cloud Build per configurare ed eseguire l'autenticazione su GitHub. I trigger GitHub consentono di avviare automaticamente le build su push e richieste di pull Git e di visualizzare i risultati della build su GitHub e Google Cloud Console. Puoi creare e gestire i trigger GitHub usando Google Cloud Console o l'API Cloud Build, come descritto in questa pagina.

  • Trigger di GitHub Hub: questo tipo di trigger consente di richiamare le build in risposta ai commit o alle richieste di pull su un'istanza GitHub Enterprise. Puoi creare repository da GitHub Enterprise utilizzando la console Google Cloud o l'API Cloud Build.

La tabella riportata di seguito confronta i trigger GitHub, i trigger GitHub e i trigger GitHub Enterprise:

Funzionalità Trigger legacy di GitHub Trigger di GitHub Trigger di GitHub Enterprise
Eseguire build su push al codice sorgente Yes
Eseguire build su richieste di pull No
Crea trigger utilizzando Google Cloud Console Yes
Crea trigger utilizzando l'API Cloud Build No
Crea trigger utilizzando l'app GitHub di Cloud Build No
Visualizza lo stato della build in Google Cloud Console Yes
Visualizza lo stato della build su GitHub No

Condivisione dei dati

I trigger GitHub inviano dati all'app GitHub di Cloud Build. I dati inviati all'app ti aiutano a identificare i trigger per nome e a visualizzare i risultati della build su GitHub.

I seguenti dati sono attualmente condivisi tra Google Cloud e l'app GitHub:

  • ID progetto Cloud
  • Nome trigger
  • Log di build

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

Se hai attivato i controlli di stato obbligatori per un repository GitHub, l'abilitazione della condivisione dei dati potrebbe interrompere temporaneamente i controlli di stato. Puoi modificare le configurazioni dei controlli di stato in modo da cercare il nome del trigger per:

  • Disabilitazione di eventuali controlli obbligatori specifici di Cloud Build sul repository GitHub
  • Assicurati che la condivisione dei dati sia abilitata in Cloud Build
  • Esecuzione di una nuova build in Cloud Build che pubblica gli stati nel tuo repository
  • Riattivazione dei controlli di stato richiesti con selezione del nome del trigger

Passaggi successivi