Automatizzare le build in risposta agli eventi Pub/Sub

I trigger Pub/Sub di Cloud Build consentono di eseguire build in risposta agli eventi di Google Cloud pubblicati su Pub/Sub. Puoi utilizzare le informazioni di un evento Pub/Sub per parametrizzare la build e decidere se eseguire una build in risposta all'evento. Puoi configurare trigger Pub/Sub per ascoltare qualsiasi 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 (deprecato) e Cloud Storage.

Prima di iniziare

Attiva l'API Cloud Build.
Abilita l'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.

Nota: se hai già installato gcloud CLI, assicurati di avere la versione più recente disponibile eseguendo gcloud components update.

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

Puoi creare un trigger Pub/Sub che risponda agli eventi di Artifact Registry, come quando le immagini vengono inviate tramite push, taggate o eliminate. Questa sezione illustra come creare un trigger Pub/Sub che richiama una build quando viene eseguito il push di un nuovo tag a un'immagine esistente. Se non hai dimestichezza con Artifact Registry, consulta la panoramica di Artifact Registry.

Console

Per creare un trigger che ascolti un nuovo tag inviato tramite push a un'immagine esistente in Artifact Registry utilizzando la console Google Cloud:

Apri la pagina Attivatori:

Apri la pagina Attivatori
Seleziona il progetto nella parte superiore della pagina e fai clic su Apri.
Fai clic su Crea trigger.
Inserisci le seguenti impostazioni del trigger:
- Nome: inserisci un nome per l'attivatore.
- Regione: seleziona la regione per l'attivatore.
  - 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 l'attivatore.
- Evento: seleziona Messaggio Pub/Sub come evento per chiamare il trigger.
- Sottoscrizione: seleziona l'argomento Pub/Sub che vuoi sottoscrivere come evento di trigger. Puoi vedere tutti gli argomenti esistenti nel tuo progetto nel menu a discesa.
  - Argomento Pub/Sub: seleziona l'argomento gcr dal menu a discesa o crea manualmente l'argomento seguendo le istruzioni riportate in Configurare le notifiche Pub/Sub.
  Nota: dopo aver creato l'attivatore, verrà creato automaticamente un abbonamento per l'attivatore. Puoi visualizzare la tua sottoscrizione nella pagina Sottoscrizioni Pub/Sub.
- Origine: seleziona l'origine da creare quando viene eseguito il trigger di Pub/Sub. Puoi specificare 1a generazione o 2a generazione come origine.
  
  Nota: la regione del repository deve corrispondere a quella del trigger.
  - Repository: dall'elenco dei repository disponibili, seleziona il repository desiderato.
  - Ramo o Tag: specifica un'espressione regolare con il ramo o il valore del tag da abbinare. 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:
    
    Avviso: qualsiasi utente con accesso in lettura al repository può inviare una richiesta di pull, il che potrebbe 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. Per ulteriori informazioni sui privilegi dei trigger in fase di build, consulta Trigger di build e account di servizio Cloud Build.
    - 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 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 un collaboratore crea o aggiorna una richiesta di pull, le build vengono eseguite solo dopo che un proprietario o un collaboratore commenta /gcbrun la richiesta di pull. Le build vengono eseguite ogni volta che viene apportata una modifica a una richiesta di pull.
    - Non obbligatorio: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build verranno eseguite automaticamente dai trigger.
- Configurazione: seleziona il file di configurazione di compilazione (che si trova nel repository remoto) o crea un file di configurazione di compilazione incorporato 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 tua configurazione.
    - Dockerfile: utilizza un Dockerfile per la configurazione.
    - Buildpack: utilizza i buildpack per la configurazione.
  - Località: specifica la località della configurazione.
    - Repository: se il file di configurazione si trova nel repository remoto, specifica il percorso del file di configurazione della build, della directory Dockerfile o della directory buildpacks. Se il tipo di configurazione della build è Dockerfile o un buildpack, devi fornire un nome per l'immagine risultante e, facoltativamente, un timeout per la build. Dopo aver fornito il nome dell'immagine Dockerfile o buildpack, vedrai un'anteprima del comando docker build o pack che verrà eseguito dalla build.
    - (Facoltativo) Variabili di ambiente Buildpack: se hai selezionato buildpacks come tipo di configurazione, fai clic su Aggiungi variabile di ambiente buildpack per specificare le variabili e i valori di ambiente buildpack. Per scoprire di più sulle 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 di compilazione in linea. Fai clic su Apri editor per scrivere il file di configurazione della build nella console Google Cloud utilizzando la sintassi YAML o JSON. Fai clic su Fine per salvare la configurazione della build.
      
      Nota: il supporto per la configurazione della compilazione in linea non è disponibile per Dockerfile o per i buildpack.
- Sostituzioni (facoltativo): se hai selezionato il file di configurazione della build come opzione di configurazione della build, puoi scegliere di definire variabili di sostituzione specifiche per il trigger utilizzando questo campo.
  
  Nel seguente esempio, vogliamo ottenere il nome del tag immagine dal payload e l'azione associata all'evento gcr. A questo scopo, crea variabili di sostituzione utilizzando le associazioni di payload.
  
  Specifica di seguito 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 dagli editori e consumato dagli abbonati. Per altri esempi del payload delle notifiche Pub/Sub, vedi Esempi di notifiche.
  
  Nota: sebbene la definizione delle variabili di sostituzione sia facoltativa, sono obbligatorie se vuoi configurare filtri personalizzati per i messaggi Pub/Sub (per saperne di più, consulta la sezione Filtri).
- Filtri (facoltativi): puoi creare filtri all'interno di un trigger per determinare se il trigger eseguirà o meno una build in risposta al payload in arrivo specificando i filtri per le variabili di sostituzione. L'espressione di filtro deve restituire true affinché venga eseguita una build.
  
  Ti consigliamo di utilizzare i filtri durante la configurazione dei trigger Pub/Sub su argomenti con diversi messaggi. I filtri possono essere usati per controllare con precisione le build eseguite in risposta ai messaggi Pub/Sub in arrivo. Per scoprire i rischi associati alla configurazione di un trigger senza filtri, consulta Rischi associati a un trigger non filtrato.
  
  Nel seguente esempio, vogliamo che l'attivatore esegua una build se viene eseguito il push di un nuovo tag a un'immagine esistente. Utilizziamo gli operatori delle condizioni di filtro per verificare se la variabile _IMAGE_TAG corrisponde al nome di un tag esistente e se la variabile _ACTION corrisponde a INSERT per cercare i dati appena aggiunti.
  
  Specifica i seguenti filtri:
  - _IMAGE_TAG != ""
  - _ACTION == INSERT
  Nota: puoi anche nidificare le condizioni specificando i seguenti operatori booleani: && (and) e || (or). Il simbolo ! (non) non è supportato.
  
  La sintassi di filtro nei trigger Pub/Sub utilizza CEL (Common Expression Language) per la valutazione delle espressioni. Per scoprire di più su CEL, consulta il repository cel-spec.

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

Fai clic su Crea per creare il trigger di build.

gcloud

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

Apri una finestra del terminale.

Esegui il comando gcloud per creare un trigger di build nel tuo progetto. Nell'esempio riportato di seguito, l'attivatore è configurato per rispondere alle build con un tag che corrisponde a prod e un'azione corrispondente a INSERT in base al 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 il trigger.
TRIGGER_NAME è il nome dell'attivatore.
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 la sottoscrizione.
BUILD_CONFIG è il percorso del file di configurazione della build.
INLINE_BUILD_CONFIG è il percorso del file di configurazione della build incorporata.
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 il trigger per la creazione su un ramo.

Creazione di un trigger di build che risponda agli eventi di Container Registry

Puoi creare un trigger Pub/Sub che risponda agli eventi di Container Registry, come quando viene eseguito il push delle immagini, l'applicazione di tag o l'eliminazione. 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 la Guida rapida per Container Registry per scoprire come eseguire il push e il pull delle immagini con i tag.

Console

Per creare un trigger che ascolti il push di un'immagine in Container Registry e che corrisponda in base al nome di un tag utilizzando la console Google Cloud:

Apri la pagina Attivatori:

Apri la pagina Attivatori
Seleziona il progetto nella parte superiore della pagina e fai clic su Apri.
Fai clic su Crea trigger.
Inserisci le seguenti impostazioni del trigger:
- Nome: inserisci un nome per l'attivatore.
- Regione: seleziona la regione per l'attivatore.
  - 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 l'attivatore.
- Evento: seleziona Messaggio Pub/Sub come evento per chiamare il trigger.
- Sottoscrizione: seleziona l'argomento Pub/Sub che vuoi sottoscrivere come evento di trigger. Puoi vedere tutti gli argomenti esistenti nel tuo progetto nel menu a discesa.
  - Argomento Pub/Sub: seleziona l'argomento gcr dal menu a discesa o crea manualmente l'argomento seguendo le istruzioni riportate in Configurare le notifiche Pub/Sub.
  Nota: dopo aver creato l'attivatore, verrà creato automaticamente un abbonamento per l'attivatore. Puoi visualizzare la tua sottoscrizione nella pagina Sottoscrizioni Pub/Sub.
- Origine: seleziona l'origine da creare quando viene eseguito il trigger di Pub/Sub. Puoi specificare 1a generazione o 2a generazione come origine.
  
  Nota: la regione del repository deve corrispondere a quella del trigger.
  - Repository: dall'elenco dei repository disponibili, seleziona il repository desiderato.
  - Ramo o Tag: specifica un'espressione regolare con il ramo o il valore del tag da abbinare. 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:
    
    Avviso: qualsiasi utente con accesso in lettura al repository può inviare una richiesta di pull, il che potrebbe 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. Per ulteriori informazioni sui privilegi dei trigger in fase di build, consulta Trigger di build e account di servizio Cloud Build.
    - 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 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 un collaboratore crea o aggiorna una richiesta di pull, le build vengono eseguite solo dopo che un proprietario o un collaboratore commenta /gcbrun la richiesta di pull. Le build vengono eseguite ogni volta che viene apportata una modifica a una richiesta di pull.
    - Non obbligatorio: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build verranno eseguite automaticamente dai trigger.
- Configurazione: seleziona il file di configurazione di compilazione (che si trova nel repository remoto) o crea un file di configurazione di compilazione incorporato 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 tua configurazione.
    - Dockerfile: utilizza un Dockerfile per la configurazione.
    - Buildpack: utilizza i buildpack per la configurazione.
  - Località: specifica la località della configurazione.
    - Repository: se il file di configurazione si trova nel repository remoto, specifica il percorso del file di configurazione della build, della directory Dockerfile o della directory buildpacks. Se il tipo di configurazione della build è Dockerfile o un buildpack, devi fornire un nome per l'immagine risultante e, facoltativamente, un timeout per la build. Dopo aver fornito il nome dell'immagine Dockerfile o buildpack, vedrai un'anteprima del comando docker build o pack che verrà eseguito dalla build.
    - (Facoltativo) Variabili di ambiente Buildpack: se hai selezionato buildpacks come tipo di configurazione, fai clic su Aggiungi variabile di ambiente buildpack per specificare le variabili e i valori di ambiente buildpack. Per scoprire di più sulle 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 di compilazione in linea. Fai clic su Apri editor per scrivere il file di configurazione della build nella console Google Cloud utilizzando la sintassi YAML o JSON. Fai clic su Fine per salvare la configurazione della build.
      
      Nota: il supporto per la configurazione della compilazione in linea non è disponibile per Dockerfile o per i buildpack.
- Sostituzioni (facoltativo): se hai selezionato il file di configurazione della build come opzione di configurazione della build, puoi scegliere di definire variabili di sostituzione specifiche per il trigger utilizzando questo campo.
  
  Nel seguente esempio, vogliamo ottenere il nome del tag immagine dal payload e l'azione associata all'evento gcr. A questo scopo, crea variabili di sostituzione utilizzando le associazioni di payload.
  
  Specifica di seguito 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 dagli editori e consumato dagli abbonati. Per altri esempi del payload delle notifiche Pub/Sub, vedi Esempi di notifiche.
  
  Nota: sebbene la definizione delle variabili di sostituzione sia facoltativa, sono obbligatorie se vuoi configurare filtri personalizzati per i messaggi Pub/Sub (per saperne di più, consulta la sezione Filtri).
- Filtri (facoltativi): puoi creare filtri all'interno di un trigger per determinare se il trigger eseguirà o meno una build in risposta al payload in arrivo specificando i filtri per le variabili di sostituzione. L'espressione di filtro deve restituire true affinché venga eseguita una build.
  
  Ti consigliamo di utilizzare i filtri durante la configurazione dei trigger Pub/Sub su argomenti con diversi messaggi. I filtri possono essere usati per controllare con precisione le build eseguite in risposta ai messaggi Pub/Sub in arrivo. Per scoprire i rischi associati alla configurazione di un trigger senza filtri, consulta Rischi associati a un trigger non filtrato.
  
  Nel seguente esempio, vogliamo che l'attivatore esegua una build se il nome della variabile tag _IMAGE_TAG corrisponde a un nome di tag specifico, ad esempio prod. Puoi specificare l'operatore della condizione di filtro come "==" per la corrispondenza esatta. Puoi anche controllare l'azione associata al tuo evento gcr. Ad esempio, potresti voler specificare che _ACTION è INSERT per cercare i dati appena aggiunti.
  
  Specifica i seguenti filtri:
  - _IMAGE_TAG.matches(prod)
  - _ACTION.matches(INSERT)
  Nota: puoi anche nidificare le condizioni specificando i seguenti operatori booleani: && (and) e || (or). Il simbolo ! (non) non è supportato.
  
  La sintassi di filtro nei trigger Pub/Sub utilizza CEL (Common Expression Language) per la valutazione delle espressioni. Per scoprire di più su CEL, consulta il repository cel-spec. Per altri esempi di sintassi di filtro che puoi applicare ai trigger Pub/Sub, consulta Filtro delle build.

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

Fai clic su Crea per creare il trigger di build.

gcloud

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

Puoi creare un trigger Pub/Sub che risponda agli eventi di Cloud Storage, ad esempio quando viene eseguito il push di un nuovo programma binario a un bucket di archiviazione esistente. Questa sezione illustra come creare un trigger Pub/Sub che risponda con una build quando viene eseguito il deployment di un nuovo programma binario in un bucket caricato. Se non hai dimestichezza con Cloud Storage, consulta le guide rapide.

Console

Per creare un trigger in ascolto degli eventi Cloud Storage utilizzando la console Google Cloud:

Apri la pagina Attivatori:

Apri la pagina Attivatori
Seleziona il progetto nella parte superiore della pagina e fai clic su Apri.
Fai clic su Crea trigger.
Inserisci le seguenti impostazioni del trigger:
- Nome: inserisci un nome per l'attivatore.
- Regione: seleziona la regione per l'attivatore.
  - 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 l'attivatore.
- Evento: seleziona Messaggio Pub/Sub come evento per chiamare il trigger.
- Sottoscrizione: seleziona l'argomento Pub/Sub che vuoi sottoscrivere come evento di trigger. Puoi vedere tutti gli argomenti esistenti nel tuo progetto nel menu a discesa.
  - Argomento Pub/Sub: seleziona l'argomento gcs dal menu a discesa o crea manualmente l'argomento seguendo le istruzioni riportate in Configurare le notifiche Pub/Sub per Cloud Storage.
  Nota: dopo aver creato l'attivatore, verrà creato automaticamente un abbonamento per l'attivatore. Puoi visualizzare la tua sottoscrizione nella pagina Sottoscrizioni Pub/Sub.
- Origine: seleziona l'origine da creare quando viene eseguito il trigger di Pub/Sub. Puoi specificare 1a generazione o 2a generazione come origine.
  
  Nota: la regione del repository deve corrispondere a quella del trigger.
  - Repository: dall'elenco dei repository disponibili, seleziona il repository desiderato.
  - Ramo o Tag: specifica un'espressione regolare con il ramo o il valore del tag da abbinare. 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:
    
    Avviso: qualsiasi utente con accesso in lettura al repository può inviare una richiesta di pull, il che potrebbe 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. Per ulteriori informazioni sui privilegi dei trigger in fase di build, consulta Trigger di build e account di servizio Cloud Build.
    - 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 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 un collaboratore crea o aggiorna una richiesta di pull, le build vengono eseguite solo dopo che un proprietario o un collaboratore commenta /gcbrun la richiesta di pull. Le build vengono eseguite ogni volta che viene apportata una modifica a una richiesta di pull.
    - Non obbligatorio: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build verranno eseguite automaticamente dai trigger.
- Configurazione: seleziona il file di configurazione di compilazione (che si trova nel repository remoto) o crea un file di configurazione di compilazione incorporato 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 tua configurazione.
    - Dockerfile: utilizza un Dockerfile per la configurazione.
    - Buildpack: utilizza i buildpack per la configurazione.
  - Località: specifica la località della configurazione.
    - Repository: se il file di configurazione si trova nel repository remoto, specifica il percorso del file di configurazione della build, della directory Dockerfile o della directory buildpacks. Se il tipo di configurazione della build è Dockerfile o un buildpack, devi fornire un nome per l'immagine risultante e, facoltativamente, un timeout per la build. Dopo aver fornito il nome dell'immagine Dockerfile o buildpack, vedrai un'anteprima del comando docker build o pack che verrà eseguito dalla build.
    - (Facoltativo) Variabili di ambiente Buildpack: se hai selezionato buildpacks come tipo di configurazione, fai clic su Aggiungi variabile di ambiente buildpack per specificare le variabili e i valori di ambiente buildpack. Per scoprire di più sulle 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 di compilazione in linea. Fai clic su Apri editor per scrivere il file di configurazione della build nella console Google Cloud utilizzando la sintassi YAML o JSON. Fai clic su Fine per salvare la configurazione della build.
      
      Nota: il supporto per la configurazione della compilazione in linea non è disponibile per Dockerfile o per i buildpack.
- Sostituzioni (facoltativo): se hai selezionato il file di configurazione della build come opzione di configurazione della build, puoi scegliere di definire variabili di sostituzione specifiche per il trigger utilizzando questo campo.
  
  In questo esempio, vogliamo controllare il deployment di un nuovo programma binario quando viene caricato in un bucket. Per ottenere questi dati, possiamo creare variabili di sostituzione utilizzando le associazioni di payload.
  
  Specifica di seguito le variabili e i valori seguenti:
  
  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 dagli editori e consumato dagli abbonati. Per altri esempi del payload delle notifiche Pub/Sub, vedi Esempi di notifiche.
  
  Nota: sebbene la definizione delle variabili di sostituzione sia facoltativa, sono obbligatorie se vuoi configurare filtri personalizzati per i messaggi Pub/Sub (per saperne di più, consulta la sezione Filtri).
- Filtri (facoltativi): puoi creare filtri all'interno di un trigger per determinare se il trigger eseguirà o meno una build in risposta al payload in arrivo specificando i filtri per le variabili di sostituzione. L'espressione di filtro deve restituire true affinché venga eseguita una build.
  
  Ti consigliamo di utilizzare i filtri durante la configurazione dei trigger Pub/Sub su argomenti con diversi messaggi. I filtri possono essere usati per controllare con precisione le build eseguite in risposta ai messaggi Pub/Sub in arrivo. Per scoprire i rischi associati alla configurazione di un trigger senza filtri, consulta Rischi associati a un trigger non filtrato.
  
  Poiché vogliamo che il trigger esegua una build se è stato eseguito il deployment del nuovo programma binario in un bucket specifico, possiamo utilizzare l'operatore "==" per verificare le corrispondenze esatte. Puoi utilizzare anche la parola chiave "corrisponde a" se vuoi trovare una corrispondenza tramite espressione regolare.
  
  Specifica i seguenti filtri:
  - _EVENT_TYPE == OBJECT_FINALIZE
  - _OBJECT_ID corrisponde a ^<object-id>$
  - _BUCKET_ID corrisponde a ^<bucket-id>$

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

Fai clic su Crea per creare il trigger di build.

gcloud

Rischi associati a un attivatore non filtrato

Se non hai configurato i filtri sul trigger Pub/Sub, questo potrebbe finire per richiamare un numero infinito di build se il trigger modifica un artefatto o un oggetto che pubblica involontariamente un nuovo messaggio nell'argomento che sta ascoltando. Ad esempio, il trigger può richiamare un numero infinito di build se il trigger:

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 lo modifica.

Se riscontri un loop infinito, puoi eliminare il trigger o aggiornarlo in modo che punti a un argomento separato per evitare costi aggiuntivi per ogni build richiamata.

Passaggi successivi

Scopri come avviare le build manualmente utilizzando i comandi gcloud o l'API Cloud Build.
Scopri come creare e gestire gli attivatori.
Scopri come visualizzare i risultati della build.
Scopri come risolvere gli errori di generazione.