Automatizzare le build in risposta agli eventi Pub/Sub

I trigger Pub/Sub di Cloud Build consentono di eseguire le build in risposta a eventi Google Cloud pubblicati su Pub/Sub. Puoi utilizzare le informazioni di un evento Pub/Sub per parametrizzare la tua build e decidere se una build deve essere eseguita in risposta all'evento. I trigger Pub/Sub possono essere configurati 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 e Cloud Storage.

Prima di iniziare

  • Attiva l'API Cloud Build.

    Abilita l'API

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

Puoi creare un trigger Pub/Sub che risponda agli eventi Artifact Registry, ad esempio quando viene eseguito il push, il tag o l'eliminazione delle immagini. Questa sezione illustra come creare un attivatore Pub/Sub che richiami 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 caricato su un'immagine esistente in Artifact Registry utilizzando Google Cloud Console:

  1. Apri la pagina Trigger:

    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 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 Messaggio Pub/Sub come evento per richiamare l'attivatore.

    • Abbonamento: seleziona l'argomento Pub/Sub a cui vuoi abbonarti come evento di trigger. Puoi visualizzare tutti gli argomenti esistenti nel progetto nel menu a discesa.

      • Argomento Pub/Sub: seleziona l'argomento gcr dal menu a discesa o crea manualmente l'argomento utilizzando le istruzioni in Configura le notifiche Pub/Sub.
    • Origine: seleziona il repository da creare quando viene eseguito il trigger.

    • Revisione: seleziona il ramo o il tag da creare quando viene eseguito il trigger.

      • Ramo: inserisci il nome del ramo su cui richiamare la build.
      • Tag: inserisci il nome del tag su cui richiamare la build.
    • Configurazione: seleziona il file di configurazione della build (situato nel tuo repository remoto) o crea un file di configurazione della build incorporato da utilizzare per la tua 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.
        • Buildpack: utilizza buildpacks 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 della build, della directory Dockerfile o della directory buildpacks. Se il tipo di configurazione della build è Dockerfile o buildpack, dovrai fornire un nome per l'immagine risultante e, facoltativamente, un timeout per la build. Dopo aver fornito il nome dell'immagine Dockerfile o buildpack, verrà visualizzata 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 Pack per specificare le variabili e i valori dell'ambiente buildpack. Per scoprire di più sulle variabili di ambiente della build, consulta Variabili di ambiente.
        • 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.

    • (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 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 del payload.

      Specifica le seguenti variabili e valori di seguito:

      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 utilizzato dagli abbonati. Per altri esempi di payload delle notifiche Pub/Sub, consulta gli esempi di notifica.

    • (Facoltativo) Filtri: puoi creare filtri all'interno di un attivatore che determinano se l'attivatore eseguirà o meno una build in risposta al payload in entrata specificando i filtri sulle variabili di sostituzione. Affinché una build venga eseguita, l'espressione di filtro deve restituire un valore true.

      Consigliamo di utilizzare il filtro durante la configurazione di attivatori Pub/Sub su argomenti con diversi messaggi. I filtri possono essere utilizzati per controllare con precisione le build eseguite in risposta ai messaggi Pub/Sub in entrata. Per informazioni sui rischi associati alla configurazione di un trigger senza filtri, consulta la pagina relativa ai rischi associati a un trigger non filtrato.

      Nell'esempio seguente, vogliamo che il trigger esegua una build se un nuovo tag viene inviato a un'immagine esistente. Utilizziamo gli operatori delle condizioni dei filtri per controllare se la variabile _IMAGE_TAG corrisponde a un nome tag esistente e se la variabile _ACTION corrisponde a INSERT per cercare i dati appena aggiunti.

      Specifica i seguenti filtri come filtri:

      • _IMAGE_TAG != ""
      • _ACTION == INSERT

      La sintassi dei filtri nei trigger Pub/Sub utilizza il linguaggio CEL (Common Expression Language) per la valutazione delle espressioni. Per saperne di più sulla CEL, consulta il repository cel-spec. Per visualizzare altri esempi di sintassi per il filtro applicabili ai tuoi trigger Pub/Sub, consulta la sezione Utilizzo di CEL per filtrare gli eventi di build.

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

gcloud

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

  1. Apri una finestra del terminale.
  2. Esegui il comando gcloud alpha per creare un trigger di build nel tuo progetto. Nell'esempio che segue, l'attivatore è configurato per rispondere alle build con un tag corrispondente a prod e un'azione che corrisponde a INSERT in base al payload specificato, come definito dalla variabile di sostituzione _IMAGE_TAG.

     gcloud alpha builds triggers create pubsub \
       --name=TRIGGER_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)'
       --filter='_IMAGE_TAG == "" && _ACTION == "INSERT"'
       --repo=REPO_NAME
       --tag=TAG_NAME  # or --branch=BRANCH_NAME
    

    Dove:

    • TRIGGER_NAME è il nome del tuo attivatore.
    • PROJECT_ID è l'ID del tuo progetto Cloud.
    • TOPIC_NAME è il nome dell'argomento Pub/Sub a cui hai effettuato l'iscrizione.
    • BUILD_CONFIG è il percorso del tuo file di configurazione della build.
    • INLINE_BUILD_CONFIG è il percorso del tuo file di configurazione della build incorporato.
    • REPO_NAME è il nome del repository di codice sorgente su cui viene richiamata la build.
    • TAG_NAME è il nome del tag se vuoi impostare l'attivatore per la creazione di un tag.
    • BRANCH_NAME è il nome del ramo se vuoi impostare il trigger per creare un ramo.

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

Puoi creare un trigger Pub/Sub che risponda a eventi Container Registry, come il push, il tag o l'eliminazione delle immagini. Questa sezione illustra come creare un trigger Pub/Sub che richiami una build quando un'immagine corrisponde a un tag configurato 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 di immagini con i tag.

console

Per creare un attivatore che ascolti il push di un'immagine in Container Registry e la sua corrispondenza si basa su un nome tag utilizzando Google Cloud Console:

  1. Apri la pagina Trigger:

    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 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 Messaggio Pub/Sub come evento per richiamare l'attivatore.

    • Abbonamento: seleziona l'argomento Pub/Sub a cui vuoi abbonarti come evento di trigger. Puoi visualizzare tutti gli argomenti esistenti nel progetto nel menu a discesa.

      • Argomento Pub/Sub: seleziona l'argomento gcr dal menu a discesa o crea manualmente l'argomento utilizzando le istruzioni in Configura le notifiche Pub/Sub.
    • Origine: seleziona il repository da creare quando viene eseguito il trigger.

    • Revisione: seleziona il ramo o il tag da creare quando viene eseguito il trigger.

      • Ramo: inserisci il nome del ramo su cui richiamare la build.
      • Tag: inserisci il nome del tag su cui richiamare la build.
    • Configurazione: seleziona il file di configurazione della build (situato nel tuo repository remoto) o crea un file di configurazione della build incorporato da utilizzare per la tua 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.
        • Buildpack: utilizza buildpacks 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 della build, della directory Dockerfile o della directory buildpacks. Se il tipo di configurazione della build è Dockerfile o buildpack, dovrai fornire un nome per l'immagine risultante e, facoltativamente, un timeout per la build. Dopo aver fornito il nome dell'immagine Dockerfile o buildpack, verrà visualizzata 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 Pack per specificare le variabili e i valori dell'ambiente buildpack. Per scoprire di più sulle variabili di ambiente della build, consulta Variabili di ambiente.
        • 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.

    • (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 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 del payload.

      Specifica le seguenti variabili e valori di seguito:

      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 utilizzato dagli abbonati. Per altri esempi di payload delle notifiche Pub/Sub, consulta gli esempi di notifica.

    • (Facoltativo) Filtri: puoi creare filtri all'interno di un attivatore che determinano se l'attivatore eseguirà o meno una build in risposta al payload in entrata specificando i filtri sulle variabili di sostituzione. Affinché una build venga eseguita, l'espressione di filtro deve restituire un valore true.

      Consigliamo di utilizzare il filtro durante la configurazione di attivatori Pub/Sub su argomenti con diversi messaggi. I filtri possono essere utilizzati per controllare con precisione le build eseguite in risposta ai messaggi Pub/Sub in entrata. Per informazioni sui rischi associati alla configurazione di un trigger senza filtri, consulta la pagina relativa ai rischi associati a un trigger non filtrato.

      Nel seguente esempio, vogliamo che l'attivatore esegua una build se il nome della variabile del tag _IMAGE_TAG corrisponde a un nome tag specifico, ad esempio prod. Puoi specificare l'operatore della condizione del filtro come "=={quot; per la corrispondenza esatta. Puoi anche vedere l'azione associata all'evento gcr. Ad esempio, potresti voler specificare che _ACTION è INSERT per cercare i dati appena aggiunti.

      Specifica i seguenti filtri come filtri:

      • _IMAGE_TAG == prod
      • _ACTION == INSERT

      La sintassi dei filtri nei trigger Pub/Sub utilizza il linguaggio CEL (Common Expression Language) per la valutazione delle espressioni. Per saperne di più sulla CEL, consulta il repository cel-spec. Per visualizzare altri esempi di sintassi per i filtri che puoi applicare ai tuoi trigger Pub/Sub, consulta la sezione Filtrare le build.

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

gcloud

Per creare un attivatore che ascolti il push di un'immagine in Container Registry e la sua corrispondenza in base a un nome tag utilizzando i comandi gcloud:

  1. Apri una finestra del terminale.
  2. Esegui il comando gcloud alpha per creare un trigger di build nel tuo progetto. Nell'esempio che segue, l'attivatore è configurato per rispondere alle build con un tag corrispondente a prod e un'azione che corrisponde a INSERT in base al payload specificato, come definito dalla variabile di sostituzione _IMAGE_TAG.

     gcloud alpha builds triggers create pubsub \
       --name=TRIGGER_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)'
       --filter='_IMAGE_TAG == "prod" && _ACTION == "INSERT"'
       --repo=REPO_NAME
       --tag=TAG_NAME  # or --branch=BRANCH_NAME
    

    Dove:

    • TRIGGER_NAME è il nome del tuo attivatore.
    • PROJECT_ID è l'ID del tuo progetto Cloud.
    • TOPIC_NAME è il nome dell'argomento Pub/Sub a cui hai effettuato l'iscrizione.
    • BUILD_CONFIG è il percorso del tuo file di configurazione della build.
    • INLINE_BUILD_CONFIG è il percorso del tuo file di configurazione della build incorporato.
    • REPO_NAME è il nome del repository di codice sorgente su cui viene richiamata la build.
    • TAG_NAME è il nome del tag se vuoi impostare l'attivatore per la creazione di un tag.
    • BRANCH_NAME è il nome del ramo se vuoi impostare il trigger per creare un ramo.

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

Puoi creare un trigger Pub/Sub che risponda a eventi Cloud Storage, ad esempio quando viene eseguito il push di un nuovo programma binario a un bucket di archiviazione esistente. In questa sezione viene spiegato come creare un trigger Pub/Sub che risponde a una build quando viene eseguito il deployment di un nuovo programma binario in un bucket caricato. Se non hai dimestichezza con Cloud Storage, consulta la guida rapida.

console

Per creare un trigger che ascolti gli eventi Cloud Storage utilizzando Google Cloud Console:

  1. Apri la pagina Trigger:

    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 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 Messaggio Pub/Sub come evento per richiamare l'attivatore.

    • Abbonamento: seleziona l'argomento Pub/Sub a cui vuoi abbonarti come evento di trigger. Puoi visualizzare tutti gli argomenti esistenti nel progetto nel menu a discesa.

    • Origine: seleziona il repository da creare quando viene eseguito il trigger.

    • Revisione: seleziona il ramo o il tag da creare quando viene eseguito il trigger.

      • Ramo: inserisci il nome del ramo su cui richiamare la build.
      • Tag: inserisci il nome del tag su cui richiamare la build.
    • Configurazione: seleziona il file di configurazione della build (situato nel tuo repository remoto) o crea un file di configurazione della build incorporato da utilizzare per la tua 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.
        • Buildpack: utilizza buildpacks 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 della build, della directory Dockerfile o della directory buildpacks. Se il tipo di configurazione della build è Dockerfile o buildpack, dovrai fornire un nome per l'immagine risultante e, facoltativamente, un timeout per la build. Dopo aver fornito il nome dell'immagine Dockerfile o buildpack, verrà visualizzata 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 Pack per specificare le variabili e i valori dell'ambiente buildpack. Per scoprire di più sulle variabili di ambiente della build, consulta Variabili di ambiente.
        • 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.

    • (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 il trigger utilizzando questo campo.

      In questo esempio, vogliamo verificare 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 dei payload.

      Specifica le seguenti variabili e valori di seguito:

      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 utilizzato dagli abbonati. Per altri esempi di payload delle notifiche Pub/Sub, consulta gli esempi di notifica.

    • (Facoltativo) Filtri: puoi creare filtri all'interno di un attivatore che determinano se l'attivatore eseguirà o meno una build in risposta al payload in entrata specificando i filtri sulle variabili di sostituzione. Affinché una build venga eseguita, l'espressione di filtro deve restituire un valore true.

      Consigliamo di utilizzare il filtro durante la configurazione di attivatori Pub/Sub su argomenti con diversi messaggi. I filtri possono essere utilizzati per controllare con precisione le build eseguite in risposta ai messaggi Pub/Sub in entrata. Per informazioni sui rischi associati alla configurazione di un trigger senza filtri, consulta la pagina relativa ai rischi associati a un trigger non filtrato.

      Poiché vogliamo che il trigger esegua la build se è stato eseguito il deployment del nuovo programma binario in un bucket specifico, possiamo utilizzare l'operatore "=={quot; per verificare la corrispondenza esatta. Puoi anche utilizzare la parola chiave "corrisponde a" se vuoi trovare una corrispondenza in base a un'espressione regolare.

      Specifica i seguenti filtri 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

Per creare un trigger di build che ascolti gli eventi di build con un tipo di evento specifico in Cloud Storage:

  1. Apri una finestra del terminale.
  2. Esegui il comando gcloud alpha per creare un trigger di build nel tuo progetto. Nell'esempio che segue, il trigger è configurato per rispondere alle build con un evento Cloud Storage associato a un nuovo programma binario inviato a un bucket di archiviazione esistente:

     gcloud alpha builds triggers create pubsub \
       --name=TRIGGER_NAME \
       --topic=projects/PROJECT_ID/topics/TOPIC_NAME \
       --build-config=BUILD_CONFIG \ # or --inline-config=INLINE_BUILD_CONFIG
       --substitutions=\
         _EVENT_TYPE='$(body.message.attributes.eventType)'
         _BUCKET_ID='$(body.message.attributes.bucketId)'
         _OBJECT_ID='$(body.message.attributes.objectId)'
       --filter='_EVENT_TYPE == "OBJECT_FINALIZE" && _OBJECT_ID.matches("<object-id>") && _BUCKET_ID.matches("<bucket-id>")'
       --repo=REPO_NAME
       --tag=TAG_NAME  # or --branch=BRANCH_NAME
    

    Dove:

    • TRIGGER_NAME è il nome del tuo attivatore.
    • PROJECT_ID è l'ID del tuo progetto Cloud.
    • TOPIC_NAME è il nome dell'argomento Pub/Sub a cui hai effettuato l'iscrizione.
    • BUILD_CONFIG è il percorso del tuo file di configurazione della build.
    • INLINE_BUILD_CONFIG è il percorso del tuo file di configurazione della build incorporato.
    • REPO_NAME è il nome del repository di codice sorgente su cui viene richiamata la build.
    • TAG_NAME è il nome del tag se vuoi impostare l'attivatore per la creazione di un tag.
    • BRANCH_NAME è il nome del ramo se vuoi impostare il trigger per creare un ramo.

Rischi associati a un trigger non filtrato

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

  • Rimanda a un argomento gcr.
  • Crea un'immagine o un tag in gcr.
  • Rimanda a un argomento gcs per un oggetto specifico nel bucket e modifica quell'oggetto.

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

Utilizzo di CEL per filtrare gli eventi di build

Cloud Build utilizza CEL con la variabile build sui campi elencati nella risorsa Build per accedere ai campi associati all'evento di build, come l'ID trigger, l'elenco delle immagini o i valori di sostituzione. Puoi utilizzare la stringa filter per filtrare gli eventi di build nel file di configurazione di compilazione utilizzando qualsiasi campo elencato nella risorsa Build. Per trovare la sintassi esatta associata al tuo campo, consulta il file cloudbuild.proto.

Filtrare per ID attivatore

Per filtrare in base all'ID trigger, specifica il valore dell'ID trigger nel campo filter utilizzando build.build_trigger_id, dove trigger-id corrisponde all'ID trigger come stringa:

filter: build.build_trigger_id == trigger-id

Filtrare per stato

Per filtrare in base allo stato, specifica nel campo filter lo stato della build in base a cui vuoi applicare l'applicazione build.status.

L'esempio seguente mostra come filtrare gli eventi di build con uno stato SUCCESS utilizzando il campo filter:

filter: build.status == Build.Status.SUCCESS

Puoi anche filtrare le build con stati diversi. L'esempio seguente mostra come filtrare gli eventi di build con stato SUCCESS, FAILURE o TIMEOUT utilizzando il campo filter:

filter: build.status in [Build.Status.SUCCESS, Build.Status.FAILURE, Build.Status.TIMEOUT]

Per visualizzare altri valori dello stato in base ai quali puoi applicare il filtro, consulta la sezione Stato sotto il riferimento alla risorsa Build.

Filtrare per tag

Per filtrare in base al tag, specifica il valore del tag nel campo filter utilizzando build.tags, dove tag-name è il nome del tag:

filter: tag-name in build.tags

Puoi filtrare in base al numero di tag specificati nell'evento di build utilizzando size. Nell'esempio riportato di seguito, i filtri del campo filter creano eventi con esattamente due tag specificati con un tag specificato come v1:

filter: size(build.tags) == 2 && "v1" in build.tags

Filtrare tramite immagini

Per filtrare in base alle immagini, specifica il valore dell'immagine nel campo filter utilizzando build.images, dove image-name rappresenta il nome completo dell'immagine, come elencato in Container Registry, come gcr.io/example/image-one:

filter: image-name in build.images

Nell'esempio seguente, il filtro filter mostra gli eventi di build in cui gcr.io/example/image-one o gcr.io/example/image-two sono specificati come nomi di immagini:

filter: "gcr.io/example/image-one" in build.images || "gcr.io/example/image-two" in build.images

Applicazione di filtri in base all'ora

Puoi filtrare gli eventi di build in base a un'ora di creazione, un'ora di inizio o una fine della build specificando una delle seguenti opzioni nel tuo campo filter: build.create_time, build.start_time o build.finish_time.

Nell'esempio seguente, il campo filter utilizza timestamp per filtrare gli eventi di build con un'ora della richiesta per creare la build alle 06:00 del 20 luglio 2020:

filter: build.create_time == timestamp("2020-07-20:T06:00:00Z")

Puoi anche filtrare gli eventi di compilazione in base a confronti in base all'ora. Nell'esempio seguente, il campo filter utilizza timestamp per filtrare gli eventi di build con un'ora di inizio tra le 06:00 del 20 luglio 2020 e delle ore 06:00 del 30 luglio 2020.

filter: timestamp("2020-07-20:T06:00:00Z") >= build.start_time && build.start_time <= timestamp("2020-07-30:T06:00:00Z")

Per ulteriori informazioni su come i fusi orari vengono espressi in CEL, consulta la definizione della lingua dei fusi orari.

Per filtrare in base alla durata di una build, puoi utilizzare duration per confrontare i timestamp. Nell'esempio seguente, il campo filter utilizza duration per filtrare gli eventi di build con una build eseguita per almeno cinque minuti:

filter: build.finish_time - build.start_time >= duration("5m")

Filtrare in base alla sostituzione

Puoi filtrare per sostituzione specificando la variabile di sostituzione nel campo filter utilizzando build.substitutions. Nell'esempio seguente, il campo filter elenca le build che contengono la variabile di sostituzione substitution-variable e controlla se substitution-variable corrisponde al valore substitution-value specificato:

filter: build.substitutions[substitution-variable] == substitution-value

Dove:

  • substitution-variable è il nome della variabile di sostituzione.
  • substitution-value è il nome del valore di sostituzione.

Puoi anche filtrare in base ai valori delle variabili di sostituzione predefiniti. Nel seguente esempio, il campo filter elenca le build con il nome della filiale master e quelle che hanno il nome del repository github.com/user/my-example-repo. Le variabili di sostituzione predefinite BRANCH_NAME e REPO_NAME vengono trasmesse come chiavi a build.substitutions:

filter: build.substitutions["BRANCH_NAME"] == "master" && build.substitutions["REPO_NAME"] == "github.com/user/my-example-repo"

Se vuoi filtrare le stringhe utilizzando espressioni regolari, puoi utilizzare la funzione matches integrata. Nell'esempio riportato di seguito, il campo filter filtra in base alle build con uno stato FAILURE o TIMEOUT, che hanno anche una variabile di sostituzione build TAG_NAME con un valore che corrisponde all'espressione regolare v{DIGIT}.{DIGIT}.{3 DIGITS}).

filter: build.status in [Build.Status.FAILURE, Build.Status.TIMEOUT] && build.substitutions["TAG_NAME"].matches("^v\\d{1}\\.\\d{1}\\.\\d{3}$")`

Per visualizzare un elenco dei valori di sostituzione predefiniti, consulta Utilizzo di sostituzioni predefinite.

Passaggi successivi