Crea e gestisci i trigger di build

Un trigger di Cloud Build avvia automaticamente una build ogni volta che apporti modifiche al codice sorgente. Puoi configurare il trigger per creare build dal codice per ogni modifica al repository di codice sorgente o solo in caso di modifiche che soddisfano determinati criteri.

Questa pagina spiega come connettersi a repository di origine come GitHub e Bitbucket e come creare trigger di build per creare il codice nei repository.

Prima di iniziare

• Attiva l'API Cloud Build.

  Abilita l'API

• Per creare i trigger, devi disporre del ruolo Editor Cloud Build (roles/cloudbuild.builds.editor) nel progetto.
• Devi disporre di codice sorgente in Cloud Source Repositories, GitHub o Bitbucket.
• È necessario un Dockerfile o un file di configurazione di Cloud Build.

Attenzione:a partire dal 17 giugno 2024, Cloud Source Repositories non è disponibile per i nuovi clienti. Se la tua organizzazione non ha utilizzato in precedenza Cloud Source Repositories, non puoi abilitare l'API o utilizzare Cloud Source Repositories. I nuovi progetti non connessi a un'organizzazione non possono abilitare l'API Cloud Source Repositories. Le organizzazioni che hanno utilizzato Cloud Source Repositories prima del 17 giugno 2024 non sono interessate da questa modifica.

Connessione ai repository di origine

Devi connettere Cloud Build al repository di codice sorgente prima di creare il codice nel repository. I repository in Cloud Source Repositories sono connessi a Cloud Build per impostazione predefinita. Puoi creare direttamente trigger per i tuoi repository in Cloud Source Repositories senza connetterti manualmente.

Se stai connettendo un repository esterno, ad esempio uno ospitato su GitHub o Bitbucket, avrai bisogno di autorizzazioni di livello di amministratore sul repository per connettere inizialmente il tuo repository a Cloud Build. Per creare trigger in un repository già connesso a Cloud Build non sono necessarie le autorizzazioni di amministratore.

Completa i seguenti passaggi per connetterti a GitHub o Bitbucket:

1. Apri la pagina Trigger nella console Google Cloud.

   Apri la pagina Attivatori

2. Seleziona il progetto e fai clic su Apri.

3. Seleziona la regione in cui vuoi creare il trigger dal menu a discesa Regione.

   Nota: se selezioni global come regione, vengono utilizzati i pool predefiniti per eseguire la build. In caso contrario, per eseguire la build viene utilizzato un pool privato nella regione del trigger. Devi specificare il pool privato nel file di configurazione di compilazione o tramite gli argomenti di build.

4. Fai clic su Connetti repository.

5. Seleziona il repository in cui hai archiviato il codice sorgente.

   Se selezioni GitHub (con mirroring) o Bitbucket (con mirroring) come repository di origine, Cloud Build esegue il mirroring del repository in Cloud Source Repositories e utilizza il repository con mirroring per tutte le operazioni.

6. Fai clic su Continua.

7. Esegui l'autenticazione nel repository di codice sorgente con il tuo nome utente e la tua password.

8. Dall'elenco dei repository disponibili, seleziona quello che ti interessa e fai clic su Connetti.

   Per i repository esterni, come GitHub e Bitbucket, devi disporre di autorizzazioni a livello di proprietario per il progetto Google Cloud con cui stai lavorando.

9. Fai clic su Crea un trigger per continuare a creare un trigger di build per automatizzare le build del codice sorgente nel repository oppure fai clic su Fine.

Creazione di un trigger di build

Console

1. Apri la pagina Trigger nella console Google Cloud.

   Apri la pagina Attivatori

2. Seleziona il tuo progetto dal menu a discesa del selettore progetti nella parte superiore della pagina.

3. Fai clic su Apri.

4. Fai clic su Crea trigger.

5. 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, la regione selezionata per il trigger deve corrispondere a quella del pool privato.

     Se selezioni global come regione, Cloud Build utilizza la regione specificata nel file di configurazione della build per eseguire la build. Può essere la regione del pool privato, se specifichi un pool privato nel file di configurazione della build, o il pool predefinito globale se non specifichi un pool privato.

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

   • Evento: seleziona l'evento del repository per richiamare il trigger.

     • Esegui il push a un ramo: imposta il trigger per avviare una build in caso di commit in un ramo specifico.

     • Esegui il push di un nuovo tag: imposta l'attivatore per avviare una build sui commit che contengono un determinato tag.

     • Richiesta di pull: imposta il trigger per avviare una build quando vengono eseguiti i commit in una richiesta di pull.

       Nota: che siano basate su commit di ramo o commit di tag, le build vengono richiamate solo sui push all'origine remota, non in caso di modifiche locali, pre-invio o richieste di pull.

   • Origine: seleziona 1a generazione o 2a generazione come origine. Puoi connettere i repository da GitHub e GitHub Enterprise solo se selezioni 2a generazione come origine. Per scoprire di più, consulta Repository Cloud Build.

     Nota: la regione del repository deve corrispondere a quella del trigger. Se l'origine è un repository di codice sorgente Cloud, il repository non è connesso a una regione specifica, ma al tuo progetto.
     • Repository: seleziona il repository desiderato dall'elenco di repository disponibili. Per connettere un nuovo repository, consulta Connettersi ai repository di origine.
     Nota: se rinomini il repository dopo la creazione del trigger, devi aggiornare manualmente il nome del repository nel trigger. Attualmente, Cloud Build non reindirizza automaticamente le richieste di build dal trigger se il nome di un repository viene aggiornato.

     • Ramo o Tag: specifica un'espressione regolare con il valore del ramo o del tag da abbinare. Nei tag non è possibile utilizzare barre (/). Per ulteriori informazioni sulla sintassi accettabile delle espressioni regolari, consulta la sintassi RE2.

       Quando la build viene eseguita, Cloud Build copia i contenuti del repository in /workspace, la directory di lavoro predefinita per Cloud Build. Scopri di più sulle directory di lavoro nella pagina Panoramica della configurazione della build.

       Per consentire solo le build da origini specifiche, imposta un criterio dell'organizzazione per le integrazioni consentite (constraints/cloudbuild.allowedIntegrations) in modo da negare l'interazione con l'origine definita nel trigger. Il criterio dell'organizzazione esegue l'override del trigger e la build non viene eseguita. Per scoprire di più, consulta Si basa sul criterio dell'organizzazione di Gate per il tuo progetto.

     Nota: riceverai suggerimenti in base ai rami o ai tag presenti nel tuo repository. Se utilizzi un repository di 2ª generazione con più di 500 rami o tag, alcuni non saranno presenti nell'elenco. Puoi specificare un'espressione regolare manualmente.

   • File inclusi (facoltativo): le modifiche che interessano almeno uno di questi file richiamano una build. Puoi utilizzare le stringhe glob per specificare più file con caratteri jolly. I caratteri jolly accettabili includono quelli supportati da Go Match, ** e alternanza.

     Nota: ** è una versione ricorsiva di * che corrisponde a tutti i file e le directory nella directory selezionata e nelle relative sottodirectory. Ad esempio, il pattern src/* corrisponderà a src/code.py, ma ignorerà src/sub/code.py, mentre src/** corrisponderà a entrambi.

   • (Facoltativo) File ignorati: le modifiche che interessano solo i file ignorati non richiamano una build. Puoi usare le stringhe glob per specificare più file con caratteri jolly. I caratteri jolly accettabili includono quelli supportati da Go Match, ** e alternanza.

     Nota: le stringhe glob non consentono l'utilizzo di variabili di sostituzione nei file inclusi e ignorati.

     Se specifichi un file sia in File inclusi sia in File ignorati, le modifiche al file non richiamano una build. Supponi di specificare **/README.md in File ignorati per ignorare README.md in qualsiasi directory e di specificare src/* in File inclusi per avviare una build in caso di modifiche a qualsiasi file nella cartella src/. Se ora apporti una modifica a src/README.md, Cloud Build non avvierà una build. Ogni volta che esegui il push di una modifica all'origine, Cloud Build cerca tra i file modificati i file inclusi e ignorati per determinare se una build deve essere richiamata:

     • Se esegui il push di una modifica nel repository su un ramo esistente, Cloud Build controlla i file modificati tra il commit di cui hai appena eseguito il push e il commit a cui puntava il ramo in precedenza.
     • Se il tuo repository è Cloud Source Repository ed esegui il push di una modifica a un ramo appena creato, Cloud Build considera tutti i file nel repository come file modificati.
     • Se elimini un ramo, Cloud Build non avvia una build.
   Nota: i File inclusi e File ignorati possono essere specificati solo se seleziona Esegui il push a un ramo o Esegui il push di nuovo tag come Evento.

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

         Nota: il supporto per la configurazione di compilazione in linea non è disponibile per Dockerfile o per i buildpack.

   • Utilizza pool privato: questo campo viene visualizzato se hai selezionato Dockerfile come opzione di Configurazione. Seleziona questa casella di controllo se esegui la build in un pool privato.

   • Pool privato: se hai selezionato Utilizza pool privato, specifica il nome risorsa del pool privato nel modulo projects/WORKERPOOL_PROJECT_ID/locations/REGION/workerPools/WORKERPOOL_ID.

   • (Facoltativo) Variabili di sostituzione: se hai selezionato il file di configurazione di Cloud Build come opzione di configurazione della build, puoi scegliere di definire variabili di sostituzione specifiche per i trigger utilizzando questo campo. Ad esempio, supponiamo che tu stia creando più trigger in cui ogni trigger esegue il deployment della tua app in un ambiente specifico. Puoi specificare che il deployment dell'app viene eseguito in un ambiente nel file di configurazione di compilazione e quindi utilizzare questo campo per definire le variabili di sostituzione che specifichino in quale ambiente deve essere eseguito il deployment di questo trigger. Per informazioni sulla specifica dei valori di sostituzione nei file di configurazione di compilazione, consulta Sostituzione dei valori delle variabili.

   • Approvazione (facoltativo): seleziona la casella per richiedere l'approvazione prima dell'esecuzione della build.

   • Account di servizio: seleziona l'account di servizio da utilizzare quando richiami il trigger. Se non selezioni un account di servizio, viene utilizzato l'account di servizio Cloud Build predefinito.

     Nota: per le build eseguite dai trigger verrà utilizzato solo l'account di servizio specificato nel trigger. Se hai specificato un account di servizio nella configurazione della build, questo verrà ignorato durante l'esecuzione quando utilizzi i trigger.

6. Fai clic su Crea per salvare il trigger di build.

gcloud

Per creare un trigger se il codice sorgente si trova in Cloud Source Repositories:

    gcloud builds triggers create cloud-source-repositories \
    --repo=REPO_NAME \
    --branch-pattern=BRANCH_PATTERN \ # or --tag-pattern=TAG_PATTERN
    --build-config=BUILD_CONFIG_FILE \
    --service-account=SERVICE_ACCOUNT \
    --require-approval

Dove:

• REPO_NAME è il nome del tuo repository.
• BRANCH_PATTERN è il nome del ramo nel tuo repository su cui richiamare la build.
• TAG_PATTERN è il nome del tag nel tuo repository su cui richiamare la build.

• BUILD_CONFIG_FILE è il percorso del file di configurazione della build.

• SERVICE_ACCOUNT è l'indirizzo email associato al tuo account di servizio. Se non includi questo flag, verrà utilizzato l'account di servizio Cloud Build predefinito.

Nota: per le build richiamate con trigger viene utilizzato solo l'account di servizio specificato nel comando gcloud builds triggers create. I trigger di build ignorano l'account di servizio specificato nel file di configurazione della build.

• [Facoltativo] --require-approval è il flag da includere per configurare l'attivatore in modo che richieda l'approvazione.

Per un elenco completo dei flag, consulta il riferimento gcloud per la creazione di trigger per Cloud Source Repositories.

Per creare un trigger se il codice sorgente si trova in GitHub:

    gcloud builds triggers create github \
    --region=REGION \
    --repo-name=REPO_NAME \
    --repo-owner=REPO_OWNER \
    --branch-pattern=BRANCH_PATTERN \ # or --tag-pattern=TAG_PATTERN
    --build-config=BUILD_CONFIG_FILE \
    --service-account=SERVICE_ACCOUNT \
    --require-approval
    --include-logs-with-status

Dove:

• REGION è la regione per il tuo trigger.
• REPO_NAME è il nome del tuo repository.
• REPO_OWNER è il nome utente del proprietario del repository.
• BRANCH_PATTERN è il nome del ramo nel tuo repository su cui richiamare la build.
• TAG_PATTERN è il nome del tag nel tuo repository su cui richiamare la build.
• BUILD_CONFIG_FILE è il percorso del file di configurazione della build.
• SERVICE_ACCOUNT è l'indirizzo email associato al tuo account di servizio. Se non includi questo flag, verrà utilizzato l'account di servizio Cloud Build predefinito.
• [Facoltativo] --require-approval è il flag da includere per configurare l'attivatore in modo che richieda l'approvazione.
• [Facoltativo] --include-logs-with-status è un flag che puoi specificare per mostrare i log di build per i tuoi repository. Questo flag è supportato per le build da repository GitHub e GitHub Enterprise.

Nota: puoi usare il flag --include-logs-with-status solo quando crei un trigger GitHub o GitHub Enterprise utilizzando gcloud. Attualmente Cloud Build non supporta la funzionalità per la creazione di un trigger utilizzando la console Google Cloud.

Per un elenco completo dei flag, consulta la documentazione di riferimento a gcloud per la creazione di trigger per GitHub.

Dopo aver eseguito il comando gcloud per creare un trigger utilizzando Cloud Source Repositories o GitHub, dovresti vedere un output simile al seguente:

  NAME         CREATE_TIME                STATUS
  trigger-001  2019-10-30T20:45:03+00:00

Nota: il nome dell'attivatore viene generato automaticamente. Puoi modificare il nome del trigger tramite la console Google Cloud.

Test di un trigger di build

Per testare manualmente un trigger di build:

1. Apri la pagina Trigger nella console Google Cloud.

   Apri la pagina Attivatori

2. Individua il trigger nell'elenco e fai clic su Esegui trigger.

Ignorare un trigger di build

In alcuni casi, potresti voler apportare una modifica al codice sorgente, ma non vuoi richiamare una build. Ad esempio, potresti non voler richiamare una build quando aggiorni la documentazione o i file di configurazione.

In questi scenari, puoi includere [skip ci] o [ci skip] nel messaggio di commit e non verrà richiamata una build.

Se vuoi eseguire una build su quel commit in un secondo momento, usa il pulsante Esegui trigger nella pagina Trigger.

Inclusione della cronologia del repository in una build

Per creare la tua origine in un repository Git, Cloud Build esegue un clone superficiale del repository. Ciò significa che nell'area di lavoro viene eseguito il check-out nell'area di lavoro per la creazione del solo commit che ha avviato la build. Cloud Build non controlla altri rami o cronologia. Ciò garantisce l'efficienza, in modo che le build non debbano attendere di recuperare l'intero repository e la cronologia solo per creare un singolo commit.

Se vuoi includere più cronologia del repository nella build, aggiungi un passaggio nel file di configurazione della build per "unshallow" dal clone. Ad esempio:

steps:
- name: gcr.io/cloud-builders/git
  args: ['fetch', '--unshallow']
...

Nota: se la tua origine si trova in un repository Git privato, dovrai archiviare le tue credenziali in modo sicuro utilizzando Secret Manager per accedere ai comandi git come quello riportato sopra per "unshallow" dal clone del tuo repository. Per ulteriori istruzioni, vedi Accedere ai repository GitHub privati.

Per ulteriori informazioni su git fetch, consulta gitreference. Per istruzioni su come scrivere un file di configurazione di compilazione, consulta Panoramica della configurazione di compilazione.

Invio di una build per l'approvazione

Se la tua build è stata rifiutata, puoi inviarla nuovamente per l'approvazione seguendo questi passaggi nella console Google Cloud:

1. Apri la pagina Cronologia di Cloud Build nella console Google Cloud.

   Apri la pagina Cronologia di Cloud Build

2. Fai clic sull'ID della build da inviare di nuovo per l'approvazione.

3. Fai clic su Ricrea nella parte superiore della pagina per inviare nuovamente la build per l'approvazione.

La build verrà avviata quando un utente con le autorizzazioni approva la build. Per saperne di più sulle approvazioni di Cloud Build, consulta Bate di blocco all'approvazione.

Aggiornamento di un trigger di build

Console

1. Apri la pagina Trigger nella console Google Cloud.

   Apri la pagina Trigger di build

2. Seleziona il tuo progetto dal menu a discesa del selettore progetti nella parte superiore della pagina.

3. Fai clic su Apri.

4. Individua la riga con l'attivatore che vuoi aggiornare.

5. Fai clic sul menu (treni verticali) all'estremità destra della riga.

6. Seleziona Modifica.

Nota: puoi aggiornare tutti i campi associati al tuo trigger utilizzando la console Google Cloud, ad eccezione dei log di build. Consulta le gcloud istruzioni su come aggiornare un trigger di build in modo da mostrare o nascondere i log di build per i trigger di GitHub o GitHub Enterprise.

gcloud

Per aggiornare un trigger:

1. Esporta l'attivatore che vuoi aggiornare:

    gcloud beta builds triggers export TRIGGER_NAME --destination=EXPORT_PATH
   

   Dove:

   • TRIGGER_NAME è il nome del tuo trigger.
   • EXPORT_PATH è il percorso file in cui vuoi esportare il trigger. Ad esempio, puoi specificare il percorso file come examples/trigger.yaml. Tieni presente che il nome file del trigger deve avere l'estensione .yaml.

2. Apri il file contenente l'attivatore esportato.

   Il file sarà simile al seguente:

    createTime: '2022-05-26T21:56:11.830784153Z'
    filename: cloudbuild.yaml
    github:
      name: cloud-build-example
      owner: main
      push:
        branch: master
    id: 86201062-3b14-4b6a-a2fb-4ee924e8b1dd
    # remove field name and value to not show build logs
    includeBuildLogs: INCLUDE_BUILD_LOGS_WITH_STATUS
    name: trigger-001
   

3. Modifica manualmente il file per aggiornare l'attivatore.

   Per visualizzare i campi che puoi aggiungere o rimuovere dal trigger, consulta la risorsa trigger.

4. Salva il file.

5. Importa l'attivatore:

    gcloud builds triggers import --source=IMPORT_PATH
   

   Dove:

   • IMPORT_PATH è il percorso file dell'attivatore che vuoi importare.

Il trigger di build è ora aggiornato.

Disabilitazione di un trigger di build

Console

1. Apri la pagina Trigger nella console Google Cloud.

   Apri la pagina Trigger di build

2. Seleziona il tuo progetto dal menu a discesa del selettore progetti nella parte superiore della pagina.

3. Fai clic su Apri.

4. Individua la riga con l'attivatore che vuoi disabilitare.

5. Fai clic sul menu (treni verticali) all'estremità destra della riga.

6. Seleziona Disable (Disattiva).

gcloud

Per disattivare un trigger:

1. Esporta l'attivatore che vuoi disabilitare:

    gcloud beta builds triggers export TRIGGER_NAME --destination=EXPORT_PATH
   

   Dove:

   • TRIGGER_NAME è il nome del tuo trigger.
   • EXPORT_PATH è il percorso file in cui vuoi esportare il trigger. Ad esempio, puoi specificare il percorso file come examples/trigger.yaml. Tieni presente che il nome file del trigger deve avere l'estensione .yaml.

2. Apri il file contenente l'attivatore esportato.

   Il file sarà simile al seguente:

    createTime: '2020-02-21T20:02:50.215599013Z'
    description: Push to any branch
    filename: cloudbuild.yaml
    github:
      name: example-repo-name
      owner: example-owner
      push:
        branch: .*
    id: example-id
    name: Push-to-any-branch
    tags:
    - github-default-push-trigger
   

3. Aggiungi il campo disabled alla fine del file e imposta il valore su True.

    disabled: True
   

4. Salva il file.

5. Importa l'attivatore:

    gcloud builds triggers import --source=IMPORT_PATH
   

   Dove:

   • IMPORT_PATH è il percorso file dell'attivatore che vuoi importare.

Il trigger di build è ora disabilitato.

Nota: la disattivazione di un trigger tramite i comandi gcloud potrebbe non funzionare se al trigger non è associato un file di configurazione di compilazione.

La disattivazione di un trigger non ne comporta l'eliminazione. Per eliminare un trigger, consulta Eliminare un trigger di build. Un attivatore può essere riattivato modificando lo stato in Attivato.

Eliminazione di un trigger di build

Console

1. Apri la pagina Trigger nella console Google Cloud.

   Apri la pagina Trigger di build

2. Seleziona il tuo progetto dal menu a discesa del selettore progetti nella parte superiore della pagina.

3. Fai clic su Apri.

4. Individua la riga con l'attivatore che vuoi eliminare.

5. Fai clic sul menu (treni verticali) all'estremità destra della riga.

6. Seleziona Elimina.

gcloud

Per eliminare un trigger, esegui questo comando:

  gcloud builds triggers delete TRIGGER_NAME

Dove:

• TRIGGER_NAME è il nome del tuo trigger.

Per un elenco completo dei flag, consulta la documentazione di riferimento di gcloud su come eliminare gli attivatori.

Implicazioni per la sicurezza dei trigger di build

Nota: per migliorare la security posture predefinita dei tuoi progetti, Cloud Build introdurrà modifiche che richiederanno di selezionare esplicitamente un account di servizio quando crei un trigger in nuovi progetti. Per ulteriori informazioni, consulta Modifica dell'account di servizio Cloud Build.

Per impostazione predefinita, i trigger di build utilizzano l'account di servizio Cloud Build per eseguire le build, il che potrebbe fornire autorizzazioni in fase di build agli utenti che utilizzano i trigger per eseguire una build. Tieni presenti le seguenti implicazioni per la sicurezza quando utilizzi i trigger di build:

• Un utente senza accesso al progetto Cloud, ma con accesso in scrittura al repository associato ai trigger di build nel progetto, avrà le autorizzazioni per modificare il codice in fase di creazione.
• Se utilizzi i trigger per richieste di pull di GitHub, qualsiasi utente con accesso in lettura al repository può inviare una richiesta di pull, il che può eseguire una build che include modifiche al codice nella richiesta di pull. Per informazioni su come disabilitare questo comportamento per i trigger delle richieste di pull GitHub, consulta la pagina sulla creazione dei trigger GitHub.

È consigliabile creare un account di servizio con solo i ruoli richiesti per il trigger. Per scoprire di più, consulta Configurare gli account di servizio specificati dall'utente. Per saperne di più sull'account di servizio Cloud Build e sulle autorizzazioni associate, consulta Account di servizio Cloud Build.

Passaggi successivi

• Scopri come avviare manualmente le build o configurare deployment che richiedono la chiamata manuale creando manualmente il codice nei repository di codice sorgente.
• Scopri come creare trigger GitHub.
• Scopri come automatizzare le build in risposta agli eventi Pub/Sub.
• Scopri come automatizzare le build in risposta agli eventi webhook.
• Scopri come visualizzare i risultati della build per i trigger di build.
• Scopri come eseguire deployment blu/verde su Compute Engine.
• Scopri come risolvere gli errori di build.