Creazione di repository da GitHub

I trigger di GitHub ti consentono di creare automaticamente richieste push e di pull di Git e visualizzare i risultati delle tue build su GitHub e console. Inoltre, i trigger di GitHub supportano tutte le funzionalità supportate dai triggers esistenti e utilizzano l'app GitHub di Cloud Build per configurare e autenticarsi su GitHub.

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

Prima di iniziare

  • Attiva l'API Cloud Build.

    Abilita l'API

Creazione di un trigger GitHub

console

Per creare trigger GitHub utilizzando Google Cloud Console:

  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 global come area geografica, Cloud Build utilizza il pool predefinito per eseguire la tua 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, l'area geografica 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 tua build nella stessa area geografica 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 determinato ramo.

      • Push del nuovo tag: imposta l'attivatore per avviare una build sui commit che contengono un determinato tag.

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

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

      • Repository: seleziona dall'elenco i repository disponibili. Per connettere un nuovo repository, consulta 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 un collaboratore del repository, le build vengono eseguite automaticamente dal trigger. Se un collaboratore esterno avvia l'azione, le build vengono 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 qualsiasi collaboratore, le build vengono eseguite automaticamente dagli attivatori.

    • File inclusi (facoltativo): 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 che si trova nel repository remoto o crea un file di configurazione della build in linea da utilizzare per la build.

      • Tipo: seleziona il tipo di configurazione da utilizzare per la build.
        • File di configurazione Cloud Build (yaml o json): Utilizza un file di configurazione di compilazione per la tua configurazione.
        • Dockerfile: utilizza un Dockerfile per la configurazione.
      • Località: specifica la posizione per la configurazione.

        • Repository: se il file di configurazione si trova nel repository remoto, fornisci la posizione del file di configurazione 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 nella build.
        • Inline: se hai selezionato File di configurazione di Cloud Build (yaml o json), puoi specificare la configurazione di compilazione 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.
  6. Fai clic su Crea per salvare il trigger di build.

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

gcloud

Per creare 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 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 mostrare i log di build per i tuoi repository. Questo flag è supportato per le build da repository GitHub e GitHub Enterprise. Per informazioni su come visualizzare i log di build, consulta Visualizzazione dei log di build.

Creazione e visualizzazione delle modifiche

Per creare utilizzando i trigger di GitHub, devi eseguire il push e il commit delle modifiche nel repository di codice sorgente connesso o configurare la build nelle richieste di pull. Dopo aver controllato le modifiche, Cloud Build creerà il codice.

Per visualizzare le modifiche alla build in GitHub, vai alla scheda Controlli del tuo repository.

Screenshot della scheda Conversazione

Vedrai che Cloud Build ha creato le modifiche. Vedrai anche altri dettagli della 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. Si apre la pagina Dettagli build nella console, in cui puoi visualizzare le informazioni sulla build come stato, log e passaggi della build.

Diversi tipi di trigger basati su GitHub

Se il tuo codice sorgente si trova 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 repository GitHub in Cloud Source Repositories e utilizza il repository con mirroring per tutte le sue operazioni. Puoi creare e gestire i trigger di GitHub utilizzando la console.

  • Trigger di GitHub: questo tipo di trigger utilizza l'app GitHub di Cloud Build per configurare e autenticare il GitHub. I trigger di GitHub ti consentono di avviare automaticamente le build nei push push e delle richieste di pull Git e di visualizzare i risultati della build su GitHub e sulla console. Puoi creare e gestire i trigger di GitHub usando la 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 a commit o richieste di pull su un'istanza GitHub Enterprise. Puoi creare repository da GitHub Enterprise utilizzando la console o l'API Cloud Build.

La tabella riportata di seguito mette a confronto 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 sui push al codice sorgente
Eseguire build sulle richieste di pull No
Crea trigger utilizzando la console
Crea trigger utilizzando l'API Cloud Build No
Crea trigger utilizzando l'app GitHub di Cloud Build No
Visualizza lo stato della build sulla console
Visualizza lo stato della build su GitHub No

Condivisione dei dati

I trigger di GitHub inviano dati all'app GitHub di Cloud Build. I dati inviati all'app ti aiutano a identificare i trigger per nome e 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 abilitata per il tuo progetto. Puoi abilitare la condivisione dei dati per tutti i trigger di GitHub nel tuo progetto facendo clic su Abilita nella scheda di condivisione dei dati di Cloud Build.

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

  • Disabilitazione di tutti i controlli obbligatori specifici di Cloud Build sul repository GitHub
  • Garantire che la condivisione dei dati sia abilitata in Cloud Build
  • Esecuzione di una nuova build in Cloud Build, che pubblica gli stati nel repository
  • Riattivazione dei controlli di stato richiesti con selezione del nome dell'attivatore

Passaggi successivi