Automatizzare le build in risposta agli eventi Pub/Sub

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

Limitazioni

I trigger Pub/Sub di Cloud Build non sono supportati quando si utilizza Controlli di servizio VPC.

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.

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 viene eseguito il push delle immagini, i tag o l'eliminazione. 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 rimane in ascolto di un nuovo tag inviato tramite push a un'immagine esistente in Artifact Registry utilizzando la console Google Cloud:

  1. Apri la pagina Attivatori:

    Apri la pagina Attivatori

  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 il tuo trigger.

      • Se 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, 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 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 richiamare il trigger.

    • Sottoscrizione: seleziona l'argomento Pub/Sub a cui vuoi sottoscrivere la sottoscrizione come evento 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.

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

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

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

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

        • Obbligatorio, tranne che per proprietari e collaboratori: quando una richiesta di pull viene creata o aggiornata dal proprietario o da un collaboratore di un repository, le build vengono eseguite automaticamente dal trigger. Se un collaboratore esterno avvia l'azione, le build vengono eseguite solo dopo che un proprietario o un collaboratore commenta /gcbrun sulla richiesta di pull.

        • Obbligatorio: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build vengono eseguite solo dopo che un proprietario o un collaboratore commenta /gcbrun alla 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 vengono 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 tua 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.
        • Buildpacks: utilizza buildpacks per la tua configurazione.

      • Posizione: specifica la posizione per la configurazione.

        • Repository: se il file di configurazione si trova nel repository remoto, specifica la posizione del file di configurazione della build, della directory Dockerfile o della directory buildpacks. Se il tipo di configurazione di build è Dockerfile o 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 Pack per specificare le variabili e i valori di ambiente buildpack. Per saperne di più sulle variabili di ambiente buildpack, consulta Variabili di ambiente.

        • In linea: se hai selezionato l'opzione di configurazione File di configurazione Cloud Build (yaml o json), puoi specificare la configurazione della build 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.

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

      Nell'esempio seguente, vogliamo ottenere il nome del tag immagine dal payload e dall'azione associata all'evento gcr. Per farlo, crea variabili di sostituzione utilizzando 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 dagli abbonati. Per altri esempi di payload delle notifiche Pub/Sub, vedi Esempi di notifiche.

    • (Facoltativo) Filtri: puoi creare filtri all'interno di un trigger che determina se il trigger eseguirà o meno una build in risposta al payload in arrivo specificando filtri sulle variabili di sostituzione. Per poter eseguire una build, l'espressione di filtro deve restituire true.

      Ti consigliamo di utilizzare i filtri durante la configurazione dei trigger Pub/Sub per gli argomenti con diversi messaggi. Puoi usare i filtri 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.

      Nell'esempio seguente, vogliamo che il trigger 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 nuovi dati aggiunti.

      Specifica quanto segue come filtri:

      • _IMAGE_TAG != ""
      • _ACTION == INSERT

      Per la valutazione delle espressioni, la sintassi dei filtri nei trigger Pub/Sub usa Common Expression Language (CEL). 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 trigger che rimane in ascolto di un nuovo tag inviato tramite push a 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, l'attivatore è configurato per rispondere alle build con un tag corrispondente 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 tuo trigger.
  • 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 la sottoscrizione.
  • BUILD_CONFIG è il percorso del file di configurazione della build.
  • INLINE_BUILD_CONFIG è il percorso del tuo file di configurazione della build incorporato.
  • 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 creare su un ramo.

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

Puoi creare un trigger Pub/Sub che risponda agli eventi di Container Registry, ad esempio quando viene eseguito il push, l'assegnazione di tag o l'eliminazione delle immagini. 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 trova corrispondenze in base al nome di un tag utilizzando la console Google Cloud:

  1. Apri la pagina Attivatori:

    Apri la pagina Attivatori

  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 il tuo trigger.

      • Se 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, 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 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 richiamare il trigger.

    • Sottoscrizione: seleziona l'argomento Pub/Sub a cui vuoi sottoscrivere la sottoscrizione come evento 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.

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

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

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

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

        • Obbligatorio, tranne che per proprietari e collaboratori: quando una richiesta di pull viene creata o aggiornata dal proprietario o da un collaboratore di un repository, le build vengono eseguite automaticamente dal trigger. Se un collaboratore esterno avvia l'azione, le build vengono eseguite solo dopo che un proprietario o un collaboratore commenta /gcbrun sulla richiesta di pull.

        • Obbligatorio: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build vengono eseguite solo dopo che un proprietario o un collaboratore commenta /gcbrun alla 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 vengono 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 tua 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.
        • Buildpacks: utilizza buildpacks per la tua configurazione.

      • Posizione: specifica la posizione per la configurazione.

        • Repository: se il file di configurazione si trova nel repository remoto, specifica la posizione del file di configurazione della build, della directory Dockerfile o della directory buildpacks. Se il tipo di configurazione di build è Dockerfile o 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 Pack per specificare le variabili e i valori di ambiente buildpack. Per saperne di più sulle variabili di ambiente buildpack, consulta Variabili di ambiente.

        • In linea: se hai selezionato l'opzione di configurazione File di configurazione Cloud Build (yaml o json), puoi specificare la configurazione della build 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.

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

      Nell'esempio seguente, vogliamo ottenere il nome del tag immagine dal payload e dall'azione associata all'evento gcr. Per farlo, crea variabili di sostituzione utilizzando 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 dagli abbonati. Per altri esempi di payload delle notifiche Pub/Sub, vedi Esempi di notifiche.

    • (Facoltativo) Filtri: puoi creare filtri all'interno di un trigger che determina se il trigger eseguirà o meno una build in risposta al payload in arrivo specificando filtri sulle variabili di sostituzione. Per poter eseguire una build, l'espressione di filtro deve restituire true.

      Ti consigliamo di utilizzare i filtri durante la configurazione dei trigger Pub/Sub per gli argomenti con diversi messaggi. Puoi usare i filtri 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 del tag _IMAGE_TAG corrisponde a un nome tag specifico, ad esempio prod. Puoi specificare l'operatore delle condizioni di filtro come "==" per la corrispondenza esatta. Puoi anche controllare l'azione associata al tuo evento gcr. Ad esempio, puoi specificare che _ACTION è INSERT per cercare i dati appena aggiunti.

      Specifica quanto segue come filtri:

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

      Per la valutazione delle espressioni, la sintassi dei filtri nei trigger Pub/Sub usa Common Expression Language (CEL). Per scoprire di più su CEL, consulta il repository cel-spec. Per visualizzare altri esempi di sintassi di filtro che potresti applicare ai trigger 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 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 si esegue 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 che ascolti eventi di Cloud Storage utilizzando la console Google Cloud:

  1. Apri la pagina Attivatori:

    Apri la pagina Attivatori

  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 il tuo trigger.

      • Se 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, 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 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 richiamare il trigger.

    • Sottoscrizione: seleziona l'argomento Pub/Sub a cui vuoi sottoscrivere la sottoscrizione come evento trigger. Puoi vedere tutti gli argomenti esistenti nel tuo progetto nel menu a discesa.

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

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

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

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

        • Obbligatorio, tranne che per proprietari e collaboratori: quando una richiesta di pull viene creata o aggiornata dal proprietario o da un collaboratore di un repository, le build vengono eseguite automaticamente dal trigger. Se un collaboratore esterno avvia l'azione, le build vengono eseguite solo dopo che un proprietario o un collaboratore commenta /gcbrun sulla richiesta di pull.

        • Obbligatorio: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build vengono eseguite solo dopo che un proprietario o un collaboratore commenta /gcbrun alla 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 vengono 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 tua 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.
        • Buildpacks: utilizza buildpacks per la tua configurazione.

      • Posizione: specifica la posizione per la configurazione.

        • Repository: se il file di configurazione si trova nel repository remoto, specifica la posizione del file di configurazione della build, della directory Dockerfile o della directory buildpacks. Se il tipo di configurazione di build è Dockerfile o 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 Pack per specificare le variabili e i valori di ambiente buildpack. Per saperne di più sulle variabili di ambiente buildpack, consulta Variabili di ambiente.

        • In linea: se hai selezionato l'opzione di configurazione File di configurazione Cloud Build (yaml o json), puoi specificare la configurazione della build 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.

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

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

      Specifica 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 dai publisher e utilizzato dagli abbonati. Per altri esempi di payload delle notifiche Pub/Sub, vedi Esempi di notifiche.

    • (Facoltativo) Filtri: puoi creare filtri all'interno di un trigger che determina se il trigger eseguirà o meno una build in risposta al payload in arrivo specificando filtri sulle variabili di sostituzione. Per poter eseguire una build, l'espressione di filtro deve restituire true.

      Ti consigliamo di utilizzare i filtri durante la configurazione dei trigger Pub/Sub per gli argomenti con diversi messaggi. Puoi usare i filtri 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 usare l'operatore "==" per verificare le corrispondenze esatte. Puoi anche utilizzare la parola chiave "corrisponde" se vuoi trovare corrispondenze con l'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 trigger potrebbe richiamare un numero infinito di build se modifica un artefatto o un oggetto che pubblica involontariamente un nuovo messaggio nell'argomento che sta ascoltando. Ad esempio, il trigger potrebbe 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 modifica l'oggetto.

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

Passaggi successivi