Cloud Build ti consente di creare trigger per la creazione da repository ospitati su GitHub. Puoi eseguire build in risposta a eventi come push di commit o richieste di unione associate al tuo repository GitHub.
Questa pagina spiega come attivare i trigger di build per un'istanza GitHub. Per ulteriori informazioni, consulta Trigger Cloud Build e Repository Cloud Build.
Prima di iniziare
Segui le istruzioni per connetterti a un host GitHub.-
Enable the Cloud Build API.
Per creare un trigger per un repository GitHub, devi disporre di una connessione tra Google Cloud e il tuo repository. Per creare una connessione tramite l'app GitHub in Google Cloud, consulta Connettersi a un repository GitHub.
Creare un trigger GitHub
Questa sezione spiega come creare un trigger e collegarlo all'installazione di GitHub.
Console Google Cloud
Per creare trigger GitHub utilizzando la console Google Cloud , segui questi passaggi:
Apri la pagina Trigger nella console Google Cloud .
Seleziona il tuo progetto Google Cloud e fai clic su Apri.
Fai clic su Crea trigger.
Inserisci le seguenti impostazioni del trigger:
Nome: inserisci un nome per il trigger.
Regione: seleziona la regione per il trigger.
- 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 il trigger.
Evento: seleziona l'evento del repository per richiamare il trigger.
Push a un ramo: imposta il trigger per avviare una build quando vengono eseguiti commit a un ramo specifico.
Push new tag: imposta il trigger per avviare una build sui commit che contengono un tag specifico.
Richiesta di pull: imposta il trigger per avviare una build in base ai commit di una richiesta di pull.
Origine: configura le informazioni sul tuo repository GitHub:
Servizio di repository: seleziona Cloud Build.
Generazione del repository: seleziona Developer Connect come origine.
Repository: seleziona il repository dall'elenco dei repository disponibili.
Branch o Tag: specifica un'espressione regolare con il valore del ramo o del tag da soddisfare. Per informazioni sulla sintassi accettabile delle espressioni regolari, vedi sintassi RE2.
Controllo dei commenti: se hai selezionato Richiesta di pull come Evento, scegli una delle seguenti opzioni per controllare se una build viene eseguita automaticamente dal trigger:
Obbligatorio tranne che per proprietari e collaboratori: quando una richiesta pull viene creata o aggiornata da un proprietario o 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
la 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 ha commentato
/gcbrun
la richiesta di pull. Le build vengono eseguite ogni volta che viene apportata una modifica a una richiesta di pull.Non richiesto: quando una richiesta pull viene creata o aggiornata da qualsiasi collaboratore, le build vengono eseguite automaticamente dai trigger.
Configurazione: seleziona il file di configurazione della build che si trova nel repository remoto o crea un file di configurazione della build 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 file
cloudbuild.yaml
oDockerfile
. - File di configurazione di Cloud Build (yaml o json): utilizza un file di configurazione della build per la configurazione.
- Dockerfile: utilizza un
Dockerfile
per la configurazione. - Buildpacks: utilizza i buildpack per la configurazione.
- Rilevato automaticamente: Cloud Build rileva automaticamente il tipo di configurazione se nel repository è presente un file
Posizione: specifica la posizione 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
e un nome per l'immagine risultante. Se la tua configurazione è unDockerfile
, puoi facoltativamente fornire un timeout per la build. Dopo aver fornito ilDockerfile
e il nome dell'immagine, vedrai un'anteprima del comandodocker build
che verrà eseguito dalla build. - Inline: se hai selezionato File di configurazione di Cloud Build (yaml o json) come opzione di configurazione, puoi specificare la configurazione della build in linea. Fai clic su Apri editor per scrivere il file di configurazione della build nella consoleGoogle Cloud utilizzando la sintassi YAML o JSON. Fai clic su Fine per salvare la configurazione della build.
- Repository: se il file di configurazione si trova nel repository remoto, fornisci la posizione del file di configurazione della build o della directory
- Tipo: seleziona il tipo di configurazione da utilizzare per la build.
(Facoltativo) Variabili di sostituzione: se hai selezionato il file di configurazione 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 dell'app in un ambiente specifico. Puoi specificare che la tua app venga sottoposta a deployment in un ambiente nel file di configurazione della build e poi utilizzare questo campo per definire le variabili di sostituzione che specificano l'ambiente in cui deve essere eseguito il deployment di questo trigger. Per informazioni su come specificare i valori di sostituzione nei file di configurazione della build, vedi Sostituzione dei valori delle variabili.
Log di build (facoltativo): seleziona la casella per inviare i log di build a GitHub. Per scoprire come visualizzare i log di build, consulta Visualizzazione dei log di build.
Service account: seleziona il account di servizio da utilizzare quando richiami il trigger. Se la policy dell'organizzazione consente l'utilizzo del account di servizio Cloud Build legacy, puoi lasciare questo campo vuoto per utilizzare il account di servizio legacy. In caso contrario, devi selezionare il account di servizio specifico da utilizzare, anche se si tratta del account di servizio predefinito di Compute Engine.
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.
Interfaccia a riga di comando gcloud
Per creare trigger GitHub utilizzando i comandi gcloud
, esegui questo comando:
gcloud alpha builds triggers create developer connect
--name=TRIGGER_NAME \
--git-repository-link=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/gitRepositoryLinks/REPO_NAME \
--branch-pattern=BRANCH_PATTERN # or --tag-pattern=TAG_PATTERN \
--build-config=BUILD_CONFIG_FILE \
--region=REGION \
--service-account=SERVICE-ACCOUNT
Dove:
- TRIGGER_NAME è il nome dell'attivatore.
- PROJECT_ID è l'ID progetto Google Cloud .
- REGION è la regione del trigger.
- CONNECTION_NAME è il nome della tua connessione GitHub.
- GIT_REPOSITORY_LINK è il link al tuo repository Git.
- BRANCH_PATTERN è il nome del ramo nel tuo repository su cui 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.
- SERVICE-ACCOUNT è il account di servizio da utilizzare per le operazioni di trigger e build.
API
Per creare un trigger GitHub con l'API, utilizza il seguente modello JSON:
{
"filename": "cloudbuild.yaml",
"name": "TRIGGER_NAME",
"description": "TRIGGER_DESCRIPTION",
"serviceAccount": "SERVICE_ACCOUNT",
"github": {
"owner": "OWNER",
"name": "REPO_NAME",
"push": {
"branch": ".*"
},
},
"include_build_logs": include-build-logs-value
}
Dove:
- TRIGGER_NAME è un nome per l'attivatore.
- TRIGGER_DESCRIPTION è una descrizione del trigger.
- SERVICE_ACCOUNT è il account di servizio da utilizzare per le operazioni di trigger e build.
- OWNER è il proprietario del repository GitHub.
- REPO_NAME è il nome del repository GitHub.
- include-build-logs-value è il valore del campo
facoltativo
include_build_logs
. Se questo campo ha un valoreINCLUDE_BUILD_LOGS_SPECIFIED
, i log di build vengono visualizzati nel repository.
Inserisci questo comando curl
nel terminale:
curl -X POST -H "Authorization: Bearer "$(gcloud auth print-access-token) -H "Content-Type: application/json; charset=utf-8" -H "x-goog-user-project: PROJECT_NUMBER" https://cloudbuild.googleapis.com/v1/projects/PROJECT_ID/triggers -d @trigger.json
Dove:
- PROJECT_NUMBER è il numero del tuo progetto Google Cloud .
- PROJECT_ID è l'ID progetto Google Cloud .
Creare e visualizzare le modifiche
Per eseguire la build utilizzando i trigger GitHub, devi eseguire il push e il commit delle modifiche nel repository di origine connesso o configurare la build nelle richieste di pull. Una volta archiviate le modifiche, Cloud Build compila il codice.
Per visualizzare le modifiche alla build su GitHub, vai alla scheda Controlli nel repository.
Vedrai che Cloud Build ha creato le modifiche. Vedrai anche altri dettagli della build, come il tempo impiegato per creare il codice e l'ID build.
Per visualizzare le modifiche alla build in Cloud Build, fai clic su Visualizza ulteriori dettagli su Google Cloud Build. Si apre la pagina Dettagli build nella console Google Cloud , dove puoi visualizzare informazioni sulla build come stato, log e passaggi di build.
Condivisione dei dati
I dati inviati a GitHub da Cloud Build ti aiutano a identificare i trigger per nome e a visualizzare i risultati della build su GitHub.
Attualmente, tra Cloud Build e GitHub vengono condivisi i seguenti dati:
- 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 GitHub nel tuo progetto facendo clic su Abilita nella scheda 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 modificare le configurazioni del controllo dello stato per cercare il nome del trigger:
- Disattivazione di tutti i controlli obbligatori specifici di Cloud Build nel repository GitHub
- Assicurarsi 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 obbligatori, selezione del nome del trigger
Passaggi successivi
- Scopri come creare e gestire i trigger di build.
- Scopri come eseguire deployment blu/verde su Compute Engine.