Automatizzare le build in risposta a eventi Pub/Sub

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

In questa pagina viene spiegato 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 compilazione che risponda agli eventi di 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 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 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 della build associato all'attivatore non specifica un pool privato, Cloud Build utilizza il pool predefinito per eseguire la build nella stessa regione dell'attivatore.

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

    • Evento: seleziona Messaggio Pub/Sub come evento per invocare l'attivatore.

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

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

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

      • 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 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 pull.

        • Obbligatorio: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build verranno eseguite solo dopo che un proprietario o un collaboratore avrà commentato /gcbrun la richiesta di pull. 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 qualsiasi collaboratore, le build verranno eseguite automaticamente dagli attivatori.

    • Configurazione: seleziona il file di configurazione della build (che si trova 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 della build per la tua 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 il tipo di configurazione della compilazione è Dockerfile o un buildpack, devi fornire un nome per l'immagine risultante e, facoltativamente, un timeout per la compilazione. 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ù 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 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 le associazioni di 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 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 sulle variabili di sostituzione. Affinché la compilazione venga eseguita, l'espressione del filtro deve restituire true.

      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 _IMAGE_TAG corrisponde a INSERT per cercare i dati appena aggiunti._ACTION

      Specifica quanto segue come filtri:

      • _IMAGE_TAG != ""
      • _ACTION == INSERT

      La sintassi di filtro negli attivatori Pub/Sub utilizza Common Expression Language (CEL) 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 monitora un nuovo tag inviato 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 compilazione 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 l'attivatore.
  • TRIGGER_NAME è il nome dell'attivatore.
  • PROJECT_ID è l'ID del tuo progetto Cloud.
  • CONNECTION_NAME è il nome della connessione all'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 base a 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 risponda agli eventi di Container Registry

Puoi creare un attivatore Pub/Sub che risponda agli eventi di Container Registry, ad esempio quando le immagini vengono inviate, taggate o eliminate. Questa sezione spiega come creare un trigger Pub/Sub che invoca una compilazione 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 tag.

Console

Per creare un trigger che monitora un push di immagini in Container Registry e le 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 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 della build associato all'attivatore non specifica un pool privato, Cloud Build utilizza il pool predefinito per eseguire la build nella stessa regione dell'attivatore.

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

    • Evento: seleziona Messaggio Pub/Sub come evento per invocare l'attivatore.

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

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

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

      • 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 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 pull.

        • Obbligatorio: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build verranno eseguite solo dopo che un proprietario o un collaboratore avrà commentato /gcbrun la richiesta di pull. 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 qualsiasi collaboratore, le build verranno eseguite automaticamente dagli attivatori.

    • Configurazione: seleziona il file di configurazione della build (che si trova 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 della build per la tua 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 il tipo di configurazione della compilazione è Dockerfile o un buildpack, devi fornire un nome per l'immagine risultante e, facoltativamente, un timeout per la compilazione. 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ù 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 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 le associazioni di 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 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 sulle variabili di sostituzione. Affinché la compilazione venga eseguita, l'espressione del filtro deve restituire true.

      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 il nome della variabile del tag _IMAGE_TAG corrisponde a un nome di tag specifico, ad esempio prod. Per la corrispondenza esatta, puoi specificare l'operatore della condizione del filtro come "==". 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)

      La sintassi di filtro negli attivatori Pub/Sub utilizza Common Expression Language (CEL) 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 agli attivatori Pub/Sub, consulta Filtrare le build.

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

gcloud

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

Puoi creare un attivatore Pub/Sub che risponda agli eventi Cloud Storage, ad esempio quando un nuovo file binario viene inviato a un bucket di archiviazione esistente. Questa sezione spiega come creare un trigger 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 ascolta gli eventi Cloud Storage utilizzando la console Google Cloud:

  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 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 della build associato all'attivatore non specifica un pool privato, Cloud Build utilizza il pool predefinito per eseguire la build nella stessa regione dell'attivatore.

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

    • Evento: seleziona Messaggio Pub/Sub come evento per invocare l'attivatore.

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

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

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

      • 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 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 pull.

        • Obbligatorio: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build verranno eseguite solo dopo che un proprietario o un collaboratore avrà commentato /gcbrun la richiesta di pull. 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 qualsiasi collaboratore, le build verranno eseguite automaticamente dagli attivatori.

    • Configurazione: seleziona il file di configurazione della build (che si trova 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 della build per la tua 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 il tipo di configurazione della compilazione è Dockerfile o un buildpack, devi fornire un nome per l'immagine risultante e, facoltativamente, un timeout per la compilazione. 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ù 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 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.

      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 le associazioni del 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 sulle variabili di sostituzione. Affinché la compilazione venga eseguita, l'espressione del filtro deve restituire true.

      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.

      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 la parola chiave "matches" se vuoi trovare corrispondenze tramite espressione regolare.

      Specifica quanto segue come filtri:

      • _EVENT_TYPE == OBJECT_FINALIZE
      • _OBJECT_ID partite ^<object-id>$
      • _BUCKET_ID partite ^<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 per l'attivatore Pub/Sub, l'attivatore potrebbe finire per invocare 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, l'attivatore potrebbe richiamare un numero infinito di build se:

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

Se riscontri un ciclo infinito, puoi eliminare l'attivatore o actualizarlo in modo che indichi un argomento separato per evitare di incorrere in costi aggiuntivi per ogni compilazione invocata.

Passaggi successivi