Automatizzare le build in risposta a eventi Pub/Sub

I trigger Pub/Sub di Cloud Build ti consentono eseguire build in risposta agli eventi Google Cloud pubblicati in Pub/Sub. Puoi utilizzare le informazioni di un Pub/Sub per parametrizzare la build e per decidere se una build vengono eseguite in risposta all'evento. I trigger Pub/Sub possono essere configurati di un argomento Pub/Sub.

Questa pagina spiega come creare un trigger Pub/Sub per automatizzare le build in risposta a eventi su Artifact Registry, Container Registry (Ritirato) e Cloud Storage.

Limitazioni

Gli trigger Pub/Sub di Cloud Build non sono supportati se si utilizzano Controlli di servizio VPC.

Prima di iniziare

  • Enable the Cloud Build API.

    Enable the API

  • Assicurati che il codice sorgente contenga un file di configurazione della build o un Dockerfile nel repository.

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

Creazione di un trigger di build che risponde agli eventi Artifact Registry

Puoi creare un trigger Pub/Sub che risponda agli eventi di Artifact Registry, ad esempio quando le immagini vengono inviate, taggate o eliminate. Questa sezione spiega come creare un attivatore Pub/Sub che invoca una compilazione quando un nuovo tag viene inviato a un'immagine esistente. Se non hai familiarità con Artifact Registry, consulta la panoramica di Artifact Registry.

Console

Per creare un attivatore che monitora un nuovo tag inviato a un'immagine esistente in Artifact Registry utilizzando la console Google Cloud:

  1. Apri la pagina Attivatori:

    Apri la pagina Trigger

  2. Seleziona il 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: inserisci un nome per l'attivatore.

    • Regione: seleziona la regione per il tuo trigger.

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

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

    • Evento: seleziona Messaggio Pub/Sub come evento per per richiamare il trigger.

    • Subscription: seleziona l'argomento Pub/Sub che preferisci a cui iscriversi come evento di trigger. Nel menu a discesa vengono visualizzati tutti gli argomenti esistenti nel progetto.

    • Origine: seleziona l'origine da creare quando il trigger di Pub/Sub viene eseguito. Puoi specificare 1a generazione o 2a generazione come origine.

      • Repository: dall'elenco di repository disponibili, seleziona la repository desiderato.

      • 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 pull (solo app GitHub) Evento, scegli una delle seguenti opzioni per controlla se una build verrà eseguita automaticamente dal trigger:

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

        • Obbligatorio: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build verranno eseguite solo dopo che un proprietario il collaboratore commenta /gcbrun sulla 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 (nel tuo 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 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 nel repository remoto, fornisci la posizione del file di configurazione della build, della directory Dockerfile o della directory dei buildpack. 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 buildpacks come tipo di configurazione, fai clic Aggiungi la variabile di ambiente del pacchetto per specificare il tuo buildpack variabili e valori di ambiente. 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 l'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 e salvare la configurazione della build.

    • (Facoltativo) Sostituzioni: se hai selezionato il file di configurazione della build come di configurazione della build, puoi scegliere di definire specifiche variabili di sostituzione utilizzando questo campo.

      Nell'esempio seguente, vogliamo ottenere il nome del tag immagine dal payload e l'azione associata all'evento gcr. Per farlo, per creare variabili di sostituzione associazioni di payload.

      Specifica le variabili e i valori seguenti:

      Nome variabile Valore variabile
      _IMAGE_TAG $(body.message.data.tag)
      _ACTION $(body.message.data.action)

      body.message fa riferimento a PubSubMessage pubblicato dai publisher e utilizzato dai sottoscrittori. Per altri esempi di payload di notifica Pub/Sub, consulta gli esempi di notifiche.

    • Filtri (facoltativo): puoi creare filtri all'interno di un trigger che determinano se l'trigger eseguirà o meno una compilazione in risposta al payload in entrata specificando i filtri per le variabili di sostituzione. L'espressione di filtro deve restituire true per poter build per l'esecuzione.

      Consigliamo di utilizzare i filtri quando configuri gli attivatori Pub/Sub su argomenti con più messaggi. I filtri possono essere utilizzati per controllare con precisione le build eseguite in risposta ai messaggi Pub/Sub in arrivo. Per informazioni sui rischi associati alla configurazione di un attivatore senza filtri, consulta Rischi associati a un attivatore non filtrato.

      Nell'esempio seguente, vogliamo che l'attivatore esegua una compilazione se viene inviato un nuovo tag a un'immagine esistente. Utilizziamo gli operatori della condizione di filtro per verificare se la variabile _IMAGE_TAG corrisponde a un nome di tag esistente e se la variabile _ACTION corrisponde a INSERT per cercare i dati appena aggiunti.

      Specifica quanto segue come filtri:

      • _IMAGE_TAG != ""
      • _ACTION == INSERT

      L'utilizzo dei trigger di Pub/Sub per filtrare la sintassi CEL (Common Expression Language) per la valutazione delle espressioni. Per scoprire di più su CEL, consulta il repository cel-spec.

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

gcloud

Per creare un attivatore che ascolti un nuovo tag inviato a un un'immagine esistente in Artifact Registry utilizzando i comandi gcloud:

  1. Apri una finestra del terminale.

  2. Esegui il comando gcloud per creare un trigger di build nel progetto. Nell'esempio seguente, il trigger è configurato per rispondere alle build con un tag corrispondente a prod e un'azione corrispondente a INSERT in base a il payload specificato, come definito dalla variabile di sostituzione _IMAGE_TAG.

     gcloud builds triggers create pubsub \
   --region=REGION \
   --name=TRIGGER_NAME \
   --repository=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/repositories/REPO_NAME \
   --topic=projects/PROJECT_ID/topics/TOPIC_NAME \
   --build-config=BUILD_CONFIG \ # or --inline-config=INLINE_BUILD_CONFIG
   --substitutions=\
     '_IMAGE_TAG_="$(body.message.data.tag)",' \
     '_ACTION="$(body.message.data.action)"' \
   --subscription-filter='_IMAGE_TAG == "" && _ACTION == "INSERT"' \
   --tag=TAG_NAME  # or --branch=BRANCH_NAME

Dove:

  • REGION è la regione per l'attivatore.
  • TRIGGER_NAME è il nome del tuo trigger.
  • PROJECT_ID è l'ID del tuo progetto Cloud.
  • CONNECTION_NAME è il nome della connessione host.
  • REPO_NAME è il nome del tuo repository.
  • TOPIC_NAME è il nome dell'argomento Pub/Sub a cui hai effettuato l'iscrizione.
  • BUILD_CONFIG è il percorso del file di configurazione della build.
  • INLINE_BUILD_CONFIG è il percorso del file di configurazione della build in linea.
  • TAG_NAME è il nome del tag se vuoi impostare l'attivatore in modo che si basi su un tag.
  • BRANCH_NAME è il nome del ramo se vuoi impostare l'attivatore per la compilazione in un ramo.

Creazione di un trigger di compilazione che risponde agli eventi di Container Registry

Puoi creare un trigger Pub/Sub che risponda Eventi di Container Registry, ad esempio l'esecuzione del push delle immagini, dei tag eliminati. Questa sezione illustra come creare un trigger Pub/Sub che richiama una build quando un'immagine corrisponde a un tag impostato da un filtro personalizzato. Se non hai dimestichezza con Container Registry, consulta Guida rapida per Container Registry per imparare a eseguire il push e il pull delle immagini con i tag.

Console

Creare un trigger che ascolti il push di un'immagine in Container Registry. e trova corrispondenze in base al nome di un tag utilizzando la console Google Cloud:

  1. Apri la pagina Trigger:

    Apri la pagina Trigger

  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: inserisci 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 di compilazione associato al trigger non specifica un pool privato, Cloud Build utilizza il valore predefinito pool per eseguire la build nella stessa regione come trigger.

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

    • Evento: seleziona Messaggio Pub/Sub come evento per per richiamare il trigger.

    • Subscription: seleziona l'argomento Pub/Sub che preferisci a cui iscriversi come evento di trigger. Nel menu a discesa vengono visualizzati tutti gli argomenti esistenti nel progetto.

    • Origine: seleziona l'origine da creare quando il trigger di Pub/Sub viene eseguito. Puoi specificare 1a generazione o 2a generazione come origine.

      • Repository: dall'elenco di repository disponibili, seleziona la repository desiderato.

      • 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 dall'attivatore:

        • 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 il collaboratore commenta /gcbrun sulla 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 (nel tuo 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 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 buildpacks come tipo di configurazione, fai clic Aggiungi la variabile di ambiente del pacchetto per specificare il tuo buildpack variabili e valori di ambiente. Per scoprire di più sulle variabili di ambiente del buildpack, consulta Voci di riferimento.

        • In linea: se hai selezionato File di configurazione di Cloud Build (yaml o json) come l'opzione di configurazione, puoi specificare la configurazione della build in linea. Fai clic su Apri editor per scrivere il file della configurazione di compilazione nella console Google Cloud utilizzando la sintassi YAML o JSON. Fai clic su Fine per salvare la configurazione della build.

    • (Facoltativo) Sostituzioni: se hai selezionato il file di configurazione della build come opzione di configurazione della build, puoi scegliere di definire variabili di sostituzione specifiche per l'attivatore utilizzando questo campo.

      Nell'esempio seguente, vogliamo ottenere il nome del tag immagine dal payload e l'azione associata all'evento gcr. A questo scopo, crea variabili di sostituzione utilizzando associazioni dei payload.

      Specifica le seguenti variabili e valori:

      Nome variabile Valore variabile
      _IMAGE_TAG $(body.message.data.tag)
      _ACTION $(body.message.data.action)

      body.message fa riferimento a PubSubMessage pubblicate dagli editori e consumate dagli abbonati. Per vedere altri esempi del payload della notifica Pub/Sub, consulta Esempi di notifiche.

    • Filtri (facoltativo): puoi creare filtri all'interno di un trigger che determinano se l'trigger eseguirà o meno una compilazione in risposta al payload in entrata specificando i filtri per le variabili di sostituzione. L'espressione di filtro deve restituire true per poter build per l'esecuzione.

      Consigliamo di utilizzare i filtri quando configuri gli attivatori Pub/Sub su argomenti con più messaggi. I filtri possono essere usati per controllare con precisione che vengono eseguite in risposta ai messaggi Pub/Sub in arrivo. A scopri di più sui rischi associati alla configurazione di un trigger senza filtri consulta Rischi associati a un attivatore non filtrato.

      Nell'esempio seguente, vogliamo che l'attivatore esegua una compilazione se il nome della variabile del tag _IMAGE_TAG corrisponde a un nome di tag specifico, ad esempio prod. Puoi specificare l'operatore delle condizioni di filtro come "==" per la corrispondenza esatta. Puoi anche controllare l'azione associata all'evento gcr. Ad esempio, puoi specificare _ACTION è INSERT per cercare i dati appena aggiunti.

      Specifica quanto segue come filtri:

      • _IMAGE_TAG.matches(prod)
      • _ACTION.matches(INSERT)

      L'utilizzo dei trigger di Pub/Sub per filtrare la sintassi CEL (Common Expression Language) per la valutazione delle espressioni. Per saperne di più su CEL, consulta il repository cel-spec. Per visualizzare altri esempi di sintassi dei filtri, puoi applicare Trigger di Pub/Sub. Consulta Filtrare le build.

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

gcloud

Creazione di un trigger di build che risponde agli eventi di Cloud Storage

Puoi creare un trigger Pub/Sub che risponda a Cloud Storage come il push di un nuovo file binario a un bucket di archiviazione esistente. Questa sezione spiega come creare un attivatore Pub/Sub che risponde con una compilazione durante il deployment di un nuovo file binario in un bucket caricato. Se Non hai dimestichezza con Cloud Storage, consulta le guide rapide.

Console

Per creare un trigger che ascolti eventi di Cloud Storage utilizzando la console Google Cloud:

  1. Apri la pagina Attivatori:

    Apri la pagina Trigger

  2. Seleziona il 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: inserisci un nome per l'attivatore.

    • Regione: seleziona la regione per il tuo trigger.

      • 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 nel trigger deve corrispondere alla regione in cui hai creato il pool privato.
      • Se il file di configurazione di compilazione associato al trigger non specifica un pool privato, Cloud Build utilizza il valore predefinito pool per eseguire la build nella stessa regione come trigger.

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

    • Evento: seleziona Messaggio Pub/Sub come evento per per richiamare il trigger.

    • Subscription: seleziona l'argomento Pub/Sub che preferisci a cui iscriversi come evento di trigger. Vedrai tutti gli argomenti esistenti nel progetto nel menu a discesa.

    • Origine: seleziona l'origine da creare quando il trigger di Pub/Sub viene eseguito. Puoi specificare 1ª generazione o 2ª generazione come origine.

      • Repository: dall'elenco di repository disponibili, seleziona la repository desiderato.

      • 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 pagina sulla 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:

        • Obbligatorio, tranne che per proprietari e collaboratori: quando viene eseguito un pull una richiesta viene creata o aggiornata da un proprietario o un collaboratore del repository, le build verranno eseguite automaticamente dal trigger. Se un server inizia l'azione, le build verranno eseguite solo dopo un proprietario o un collaboratore commenta /gcbrun sulla 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 il collaboratore commenta /gcbrun sulla 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 (nel tuo 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 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 della configurazione.

        • Repository: se il file di configurazione si trova nel repository remoto, fornisci la posizione del file di configurazione della build, della directory Dockerfile o della directory dei buildpack. 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 l'opzione di configurazione, puoi specificare la configurazione della build in linea. Fai clic su Apri editor per scrivere il file della configurazione di compilazione nella console Google Cloud utilizzando la sintassi YAML o JSON. Fai clic su Fine per e salvare la configurazione della build.

    • (Facoltativo) Sostituzioni: se hai selezionato il file di configurazione della build come opzione di configurazione della build, puoi scegliere di definire variabili di sostituzione specifiche per l'attivatore utilizzando questo campo.

      In questo esempio, vogliamo monitorare il deployment di un nuovo file binario quando viene caricato in un bucket. Per ottenere questi dati, possiamo creare variabili di sostituzione utilizzando associazioni di payload.

      Specifica le seguenti variabili e valori:

      Nome variabile Valore variabile
      _EVENT_TYPE $(body.message.attributes.eventType)
      _BUCKET_ID $(body.message.attributes.bucketId)
      _OBJECT_ID $(body.message.attributes.objectId)

      body.message fa riferimento a PubSubMessage pubblicato dai publisher e utilizzato dai sottoscrittori. Per vedere altri esempi del payload della notifica Pub/Sub, consulta Esempi di notifiche.

    • Filtri (facoltativo): puoi creare filtri all'interno di un trigger che determinano se l'trigger eseguirà o meno una compilazione in risposta al payload in entrata specificando i filtri per le variabili di sostituzione. L'espressione di filtro deve restituire true per poter build per l'esecuzione.

      Consigliamo di utilizzare i filtri quando configuri gli attivatori Pub/Sub su argomenti con più messaggi. I filtri possono essere usati per controllare con precisione che vengono eseguite in risposta ai messaggi Pub/Sub in arrivo. Per informazioni sui rischi associati alla configurazione di un attivatore senza filtri, consulta Rischi associati a un attivatore non filtrato.

      Poiché vogliamo che l'attivatore esegua una compilazione se il nuovo file binario è stato eseguito in un bucket specifico, possiamo utilizzare l'operatore "==" per verificare la presenza di corrispondenze esatte. Puoi anche utilizzare i "corrispondenti" se vuoi per trovare una corrispondenza con un'espressione regolare.

      Specifica quanto segue come filtri:

      • _EVENT_TYPE == OBJECT_FINALIZE
      • _OBJECT_ID corrisponde a ^<object-id>$
      • _BUCKET_ID corrisponde a ^<bucket-id>$
  1. Fai clic su Crea per creare il trigger di build.
    2. .

gcloud

Rischi associati a un attivatore non filtrato

Se non hai configurato filtri nel trigger Pub/Sub, il tuo trigger potrebbe terminare per richiamare un numero infinito di build se Il trigger modifica un artefatto o un oggetto che viene pubblicato involontariamente un nuovo messaggio per l'argomento che sta ascoltando. Ad esempio, l'attivatore potrebbe richiamare un numero infinito di build se:

  • Punta a un argomento gcr.
  • Crea qualsiasi immagine o tag in gcr.
  • Punta a un argomento gcs per un oggetto specifico nel tuo bucket e modifica l'oggetto.

Se riscontri un ciclo infinito, puoi eliminare il trigger oppure aggiornalo in modo che punti a un argomento separato per evitare di incorrere in per ogni build che richiami.

Passaggi successivi