Automatizzare le build in risposta agli eventi webhook

1a gen. 2a generazione

Cloud Build ti consente di definire trigger di webhook, che possono di autenticare e accettare gli eventi webhook in arrivo. Questi eventi, inviati a un URL personalizzato, di collegare direttamente i sistemi esterni sistemi di gestione del codice sorgente come Bitbucket.com, Bitbucket Server da GitLab a Cloud Build tramite eventi webhook.

Con i trigger webhook, puoi definire un file di configurazione di build incorporato anziché specificare un'origine durante la creazione del trigger. La configurazione della build in linea ti consente di avere il controllo sulle operazioni di git e di definire il resto della build.

Questa pagina illustra come creare trigger webhook per automatizzare le build in risposta a eventi webhook.

Nota: se stai creando un trigger che automatizza le build in base agli eventi del repository, ti consigliamo di utilizzare gli trigger dei repository Cloud Build. Repository È possibile configurare trigger che utilizzano i repository Cloud Build (2ª generazione) in modo programmatico e sono integrati in modo nativo con i provider di origine, con supporto per GitHub e GitLab. I repository Cloud Build (2ª generazione) gestiscono anche i token e le informazioni di autenticazione per tuo conto utilizzando Secret Manager. Gli attivatori del repository consentono di filtrare facilmente gli eventi in entrata e di inviare nuovamente lo stato della compilazione al provider di origine e possono anche essere configurati per funzionare con una rete privata. Per saperne di più, consulta la pagina Panoramica dei repository.

Prima di iniziare

• Enable the Cloud Build and Secret Manager APIs.

  Enable the APIs

• Per utilizzare i comandi gcloud in questa pagina, installa Google Cloud CLI.

  Nota: se hai già installato gcloud CLI in precedenza, assicurati di avere ultima versione disponibile eseguendo gcloud components update.

Creazione di trigger webhook

Console

Per creare un trigger webhook utilizzando la console Google Cloud:

1. Apri la pagina Trigger:

   Apri la pagina Trigger di build

2. Seleziona il tuo progetto nella parte superiore della pagina e fai clic su Apri.

3. Fai clic su Crea trigger.

4. Inserisci le seguenti impostazioni di trigger:

   • Nome: un nome per l'attivatore.

   • Regione: seleziona la regione per l'attivatore.

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

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

   • Evento: seleziona Evento webhook per configurare l'avvio dell'attivatore. crea in risposta agli eventi webhook in arrivo.

   • URL webhook: utilizza l'URL webhook per autenticare gli eventi webhook in entrata.

     • Secret: ti servirà un secret per autenticare gli eventi webhook in entrata. Puoi creare un nuovo secret o utilizzarne uno esistente. Questo è separato dal secret associato alla chiave SSH.

       Per creare un nuovo secret:

       1. Seleziona Utilizza un nuovo secret (generato da Cloud Build).

       2. Fai clic su Crea secret.

          Verrà visualizzata la finestra popup Crea un secret webhook.

       3. Nel campo Nome del secret, inserisci un nome per il secret.

       4. Fai clic su Crea secret per salvare il secret al fine di verranno creati e archiviati automaticamente tramite Secret Manager.

       Per utilizzare un secret esistente:

       1. Seleziona Utilizza un secret esistente o creane uno personalizzato.
       2. Nel campo Secret, seleziona il nome del secret che che desideri utilizzare dal menu a discesa o segui le istruzioni per aggiungere un secret tramite l'ID risorsa.
       3. Nel campo Versione secret, seleziona la versione del secret nel menu a discesa.

       Se utilizzi un secret esistente, potresti dover concedere manualmente il ruolo Funzione di accesso ai secret di Secret Manager Account di servizio Cloud Build, service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com. Per scoprire di più, consulta la sezione Concessione Secret Manager all'account di servizio.

     Dopo aver creato o selezionato il secret, viene visualizzata un'anteprima dell'URL webhook. L'URL conterrà una chiave API generata da Cloud Build e il tuo secret. Se Cloud Build non riesce a recuperare la tua chiave API, puoi aggiungerla manualmente all'URL o scoprire come ottenere una chiave API se non ne hai ancora una.

     Puoi utilizzare l'URL per richiamare un evento webhook inviando una richiesta HTTP utilizzando il metodo POST.

     Utilizza il seguente comando per richiamare un evento webhook:

     curl -X POST -H "Content-type: application/json" "https://cloudbuild.googleapis.com/v1/projects/${PROJECT_ID}/locations/${REGION}/triggers/${TRIGGER_NAME}:webhook?key=${API_KEY}&secret=${SECRET_VALUE}&trigger=${TRIGGER_NAME}&projectId=${PROJECT_ID}" -d "{}"
     

     Dopo aver completato questi passaggi, il ruolo Accesso ai segreti service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com di Secret Manager verrà concesso automaticamente all'agente di servizio Cloud Build,service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com. Se non vedi questo ruolo aggiunto automaticamente all'agente di servizio, completa i seguenti passaggi descritti in Concedere il ruolo Secret Manager all'account di servizio.

   • (Facoltativo) Origine: seleziona l'origine da compilare quando viene eseguito l'attivatore webhook. Se specifichi una configurazione di compilazione in linea, non è necessario specificare la seguente origine. Puoi specificare 1ª generazione o 2ª generazione come origine. Per scoprire di più, consulta Repository Cloud Build.

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

     • Repository: dall'elenco dei repository disponibili, seleziona quello che ti interessa.

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

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

       Avviso: qualsiasi utente con accesso in lettura al repository può inviare una richiesta di pull, il che può comportare l'esecuzione di 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. Puoi anche scoprire di più sui privilegi di compilazione degli attivatori.

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

       • Obbligatorio: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build verranno eseguite solo dopo che un proprietario o un collaboratore avrà commentato /gcbrun la richiesta di pull. Build vengono eseguiti ogni volta che viene apportata una modifica a una richiesta di pull.

       • Non obbligatorio: quando una richiesta di 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 in repository remoto o creare un file di configurazione di compilazione incorporato per la tua build. Se non hai specificato un repository di origine, devi selezionare un file di configurazione della build In linea come opzione di configurazione.

     • Tipo: seleziona il tipo di configurazione da utilizzare per la build.
       • 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.

     • Posizione: specifica la posizione per la configurazione.

       • Repository: se il file di configurazione si trova nella cartella repository remoto, fornisci la posizione file di configurazione della build, Dockerfile o la directory buildpacks. Se la configurazione della build è un Dockerfile o un buildpack, dovrai fornire un nome per l'immagine risultante e, facoltativamente, un timeout per creare. Dopo aver fornito il nome dell'immagine Dockerfile o del buildpack, vedrai un'anteprima del comando docker build o pack che verrà eseguito durante la compilazione.
       • (Facoltativo) Variabili di ambiente Buildpack: se hai selezionato buildpacks come tipo di configurazione, fai clic su Aggiungi variabile di ambiente del pacchetto per specificare le variabili di ambiente e i valori del buildpack. Per scoprire di più su Variabili di ambiente buildpack, consulta Variabili di ambiente.

       • In linea: 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 nell' Console Google Cloud con la sintassi YAML o JSON. Fai clic su Fine per salvare la configurazione della build.

         Nota: il supporto della configurazione di build in linea non è disponibile per Dockerfile o per i buildpack.

     Nell'esempio seguente, i log del file di configurazione della build inline ripetono "hello world":

      steps:
      - name: 'ubuntu'
        args: ['echo', 'hello world']
     

   • (Facoltativo) Sostituzioni: se hai selezionato il file di configurazione della build come di configurazione della build o un file di configurazione in linea, puoi scegliere per definire variabili di sostituzione specifiche del trigger utilizzando questo campo. Puoi anche ottenere i dati utilizzando le associazioni del payload quando definisci i valori delle variabili di sostituzione.

   • Filtri (facoltativo): puoi creare una regola all'interno di un trigger che determina se l'trigger eseguirà o meno una compilazione in base alle variabili di sostituzione.

5. Fai clic su Crea per creare il trigger di build.

gcloud

Anteprima - Webhook triggers: Cloud Build repositories (2nd gen) support

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. L'utente può trattare i dati personali relativi a questa funzionalità come descritto nell'Addendum per il trattamento dei dati Cloud, in conformità agli obblighi e alle limitazioni descritti nel contratto in base al quale accede a Google Cloud. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Per creare un attivatore webhook:

gcloud builds triggers create webhook \
  --region=REGION \
  --name=TRIGGER_NAME \
  --repository=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/repositories/REPO_NAME \
  --secret=projects/PROJECT_ID/secrets/SECRET_NAME/versions/SECRET_VERSION \
  --substitutions=_SUB_ONE='$(body.message.test)',_SUB_TWO='$(body.message.output)' \
  --subscription-filter='_SUB_ONE == "prod"' \
  --inline-config=PATH_TO_INLINE_BUILD_CONFIG \
  --tag=TAG_NAME
  # --build-config=PATH_TO_BUILD_CONFIG \
  # --branch=BRANCH_NAME

Dove:

• REGION è la regione per il tuo trigger.
• TRIGGER_NAME è il nome del tuo trigger.
• PROJECT_ID è il tuo ID progetto Cloud.
• CONNECTION_NAME è il nome della connessione all'host.
• REPO_NAME è il nome del tuo repository.
• SECRET_NAME è il nome del tuo secret archiviato in tramite Secret Manager.
• SECRET_VERSION è la versione associata al tuo come archiviato in Secret Manager.
• PATH_TO_INLINE_BUILD_CONFIG è il percorso del file di configurazione della build incorporato, se utilizzi --inline-config.
• TAG_NAME è il nome del tag se vuoi imposta l'attivatore in modo che si basi su un tag.
• PATH_TO_BUILD_CONFIG è il percorso del file di configurazione della build se utilizzi --build-config.
• BRANCH_NAME è il nome della tua filiale se vuoi impostare il trigger per la build su un ramo.

(Facoltativo) Ottenere una chiave API

Per autenticare l'evento webhook in entrata, è necessaria una chiave API.

Per ottenere una chiave API:

1. Apri la pagina Credenziali nella console Google Cloud:

   Apri la pagina Credenziali

2. Fai clic su Crea credenziali.

3. Fai clic su Chiave API.

   Verrà visualizzata una finestra di dialogo con la chiave API creata. Prendi nota chiave API.

4. Se vuoi limitare la chiave per le applicazioni del prodotto, fai clic su Limita chiave per completare ulteriori passaggi per proteggere la chiave. In caso contrario, fai clic su Chiudi.

   Per scoprire come limitare la chiave, consulta Applicazione di restrizioni relative alle chiavi API.

(Facoltativo) Concedi il ruolo Secret Manager all'account di servizio

Cloud Build concede automaticamente il ruolo Funzione di accesso ai secret di Secret Manager agli account di servizio che lo richiedono durante la configurazione dei secret. Se non vedi questo ruolo concesso automaticamente all'account di servizio necessario, completa i seguenti passaggi per aggiungerlo manualmente in modo che l'account di servizio abbia accesso alla chiave segreta:

1. Apri la pagina IAM nella console Google Cloud:

   Apri la pagina IAM

2. (Facoltativo) Per visualizzare gli account forniti da Google, seleziona Seleziona la casella di controllo Includi concessioni dei ruoli fornite da Google.

3. Prendi nota dell'account di servizio di compilazione a cui vuoi assegnare il ruolo.

4. Apri la pagina Secret Manager nella console Google Cloud:

   Apri la pagina di Secret Manager

5. Fai clic sul nome del tuo secret.

   Viene visualizzata la pagina Dettagli del secret.

   1. Fai clic sulla scheda Autorizzazioni.

   2. Fai clic su Concedi l'accesso.

      Viene visualizzato il riquadro Concedi l'accesso.

   3. Nella sezione Aggiungi entità, aggiungi l'indirizzo email associato all'account di servizio di compilazione.

   4. Nella sezione Assegna ruoli, seleziona Secret Manager > Accesso ai segreti di Secret Manager.

   5. Fai clic su Salva.

Passaggi successivi

• Scopri come creare e gestire gli attivatori.
• Scopri come creare repository ospitati su Bitbucket Server.
• Scopri come avviare manualmente le build.
• Scopri come visualizzare i risultati della build.
• Scopri come risolvere gli errori di compilazione.