Crea e gestisci i trigger di build

Un trigger di Cloud Build avvia automaticamente una build ogni volta che esegui un modifiche al codice sorgente. Puoi configurare il trigger per creare il tuo codice su qualsiasi modifiche al repository di codice sorgente o solo a quelle che soddisfano determinati criteri.

Questa pagina spiega come connetterti ai repository di origine come GitHub e Bitbucket e creare trigger di build per compilare il codice nei repository.

Prima di iniziare

• Enable the Cloud Build API.

  Enable the API

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

Attenzione: a partire dal 17 giugno 2024, Cloud Source Repositories non è più disponibile per i nuovi clienti. Se la tua organizzazione non ha Cloud Source Repositories usato in precedenza, non puoi abilitare l'API Cloud Source Repositories. I nuovi progetti non connessi a un'organizzazione non possono abilitare la l'API Cloud Source Repositories. Questa modifica non interessa le organizzazioni che hanno utilizzato i repository di origine Cloud prima del 17 giugno 2024.

Connessione ai repository di origine

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

Se colleghi un repository esterno, ad esempio uno ospitato su GitHub o Bitbucket, per collegarlo inizialmente a Cloud Build sono necessarie autorizzazioni di livello amministratore sul repository. Non sono necessarie autorizzazioni di amministratore per creare trigger in un repository che è già connesso a Cloud Build.

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 nel menu a discesa Regione.

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

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 lo utilizza per tutte le sue 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, quindi fai clic su Connetti.

   Per i repository esterni, come GitHub e Bitbucket, devi disporre delle 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 per il 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 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 della build associato all'attivatore specifica un pool privato, la regione selezionata per l'attivatore 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 piscina privata, 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.

     • Push a un ramo: imposta l'attivatore per avviare una build quando vengono eseguiti commit a un determinato ramo.

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

     • Richiesta di pull: imposta l'attivatore per avviare una compilazione su commit di una richiesta di pull.

       Nota: basate su commit di ramo o commit di tag, le build vengono solo invocata durante i push all'origine remota: non in caso di modifiche locali. o richieste di pull.

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

     Nota: la regione del repository deve corrispondere alla regione dell'attivatore. Se l'origine è un Cloud Source Repository, il repository non è collegato a una regione specifica, ma al tuo progetto.
     • Repository: dall'elenco dei repository disponibili, seleziona quello che ti interessa. Per collegare un nuovo repository, consulta Connessione 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 di build dal tuo trigger se il nome di un repository viene aggiornato.

     • Ramo o Tag: specifica un'espressione regolare con il ramo o valore del tag da far corrispondere. 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 di 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. I criteri dell'organizzazione aggiornano l'attivatore e la compilazione non viene eseguita. Per saperne di più, consulta la sezione Le build di Gate si basano sui criteri dell'organizzazione per il tuo progetto.

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

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

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

   • File ignorati (facoltativo): le modifiche che interessano solo i file ignorati non attiveranno una build. Puoi utilizzare le stringhe glob per specificare più file con caratteri jolly. I caratteri jolly accettati includono i caratteri supportati da Go Match,** e l'alternanza.

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

     Se specifichi un file sia in File inclusi sia in Ignorati file, le modifiche apportate a quel file non richiamano una build. Se specifichi **/README.md in File ignorati per ignorare README.md in qualsiasi e specifica src/* in File inclusi per avviare una build sulle modifiche apportate ai file nella cartella src/. Ora, se 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 tramite i file modificati per i file inclusi e ignorati al fine di determinare se è necessario richiamare una build:

     • Se esegui il push di una modifica nel tuo repository su un ramo esistente, Cloud Build esamina i file modificati tra il commit appena eseguito e il commit a cui il ramo faceva riferimento in precedenza.
     • Se il repository è Cloud Source Repository e esegui il push di una modifica a un ramo appena creato, quindi Cloud Build tratta tutti i file nel repository come file modificati.
     • Se elimini un ramo, Cloud Build non avvia una compilazione.
   Nota: i file inclusi e i file ignorati possono essere specificati solo se come Evento selezioni Push to a branch o Push new tag.

   • Configurazione: seleziona il file di configurazione della build che si trova in repository remoto o creare un file di configurazione di compilazione incorporato 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 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 nella cartella repository remoto, fornisci la posizione file di configurazione della build, Dockerfile o la directory buildpacks. Se il tipo di configurazione della compilazione è Dockerfile o un buildpack, dovrai 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ù su Variabili di ambiente buildpack, consulta Variabili di ambiente.

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

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

   • Use private pool: questo campo viene visualizzato se hai selezionato Dockerfile come opzione di Configurazione. Seleziona questa casella di controllo se è in esecuzione per la build in un pool privato.

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

   • (Facoltativo) Voci di sostituzione: se hai selezionato il file di configurazione Cloud Build come opzione di configurazione della build, puoi scegliere di definire variabili di sostituzione specifiche per l'attivatore utilizzando questo campo. Ad esempio, supponiamo che tu stia creando più trigger, in cui ogni attivatore esegue il deployment dell'app in un ambiente specifico. Puoi specificare che l'app viene dispiattata in un ambiente nel file di configurazione della compilazione e poi utilizzare questo campo per definire le variabili di sostituzione che specificano in quale ambiente deve essere eseguito il deployment di questo attivatore. Per informazioni su come specificare di sostituzione nei file di configurazione della build, 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 durante la chiamata il trigger. Se non selezioni un account di servizio, viene utilizzato il service account Cloud Build legacy se è disponibile per il tuo progetto.

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

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 della filiale su cui richiamare la build.
• TAG_PATTERN è il nome del tag nel repo per invocare la compilazione.
• BUILD_CONFIG_FILE è il percorso della tua build di configurazione del deployment.
• SERVICE_ACCOUNT è l'indirizzo email associato al tuo account di servizio. Se non includi questo flag, Account di servizio legacy di Cloud Build viene utilizzata se è disponibile per il tuo progetto.

Nota: solo l'account di servizio specificato nella Il comando gcloud builds triggers create è utilizzato le build richiamate con i trigger. I trigger di build ignorano il servizio specificato nel file di configurazione della build.

• [Facoltativo] --require-approval è il flag da includere per configurare l'attivatore per richiedere l'approvazione.

Per un elenco completo dei flag, consulta la pagina di riferimento gcloud su come creare attivatori 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 repository su cui invocare la compilazione.
• TAG_PATTERN è il nome del tag nel repo per invocare la compilazione.
• BUILD_CONFIG_FILE è il percorso della tua build di configurazione del deployment.
• SERVICE_ACCOUNT è l'indirizzo email associato al tuo account di servizio. Se non includi questo flag, Account di servizio legacy di Cloud Build viene utilizzata se è disponibile per il tuo progetto.
• [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 GitHub e GitHub Enterprise repository.

Nota: puoi usare solo il flag --include-logs-with-status quando si crea un trigger GitHub o GitHub Enterprise utilizzando gcloud. Cloud Build al momento non supporta la funzionalità per creare un trigger utilizzando la console Google Cloud.

Per un elenco completo dei flag, consulta la documentazione di riferimento gcloud su come creare attivatori per GitHub.

Dopo aver eseguito il comando gcloud per creare un trigger utilizzando Cloud Source Repositories o GitHub, dovresti visualizzare 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 cambiare il nome dell'attivatore tramite la console Google Cloud.

Testare un trigger di build

Per testare manualmente un trigger di build:

1. Apri la pagina Trigger nella console Google Cloud.

   Apri la pagina degli trigger

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 invocare una compilazione. Ad esempio, potresti non voler invocare una compilazione 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 compilazione

Per compilare il codice sorgente in un repository Git, Cloud Build esegue un cloning superficiale del repository. Ciò significa che solo il singolo commit che ha avviato nell'area di lavoro. Cloud Build non controlla altre sezioni o la storia. Questo viene fatto per motivi di efficienza, in modo che le compilazioni non debbano attendere il recupero dell'intero repository e della cronologia solo per compilare un singolo commit.

Se vuoi includere più cronologia del repository nella build, aggiungi una build del file di configurazione della build su "unshallow" il clone. Ad esempio:

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

Nota: se il codice sorgente si trova in un repository Git privato, dovrai memorizzare le tue credenziali in modo sicuro utilizzando Secret Manager per accedere ai comandi git, come quello riportato sopra, per "annullare l'analisi superficiale" della clonazione del tuo repository. Per ulteriori istruzioni, consulta Accedere ai repository privati GitHub.

Per ulteriori informazioni su git fetch, consulta git riferimento. Per istruzioni su come scrivere un file di configurazione della build, consulta la Panoramica della configurazione della build.

Invio di nuovo di una build per l'approvazione

Se la build è stata rifiutata, puoi inviarla di nuovo per sottoporla ad 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 che vuoi inviare di nuovo per l'approvazione.

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

La build verrà avviata quando un utente con le autorizzazioni approva la build. Per approfondire le approvazioni di Cloud Build, consulta Configurare le build all'approvazione.

Aggiornamento di un trigger di build

Console

1. Apri la pagina Trigger nella console Google Cloud.

   Apri la pagina Trigger build

2. Seleziona il 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 da aggiornare.

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

6. Seleziona Modifica.

Nota: puoi aggiornare tutti i campi associati all'attivatore utilizzando la console Google Cloud, ad eccezione della visualizzazione dei log di compilazione. Consulta le gcloud istruzioni su come aggiornare un trigger di compilazione per mostrare o nascondere i log di compilazione per gli trigger 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 del 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 dall'attivatore, consulta l'attivatore risorsa.

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 build

2. Seleziona il 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 attivatore:

1. Esporta l'attivatore che vuoi disattivare:

    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 del 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 del file dell'attivatore che vuoi importare.

Il trigger di compilazione è ora disattivato.

Nota: la disattivazione di un trigger utilizzando i comandi gcloud potrebbe non funzionare se non hai un file di configurazione di compilazione associato all'trigger.

La disattivazione di un trigger non ne comporta l'eliminazione. Per eliminare un trigger, consulta Eliminazione di 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 build

2. Seleziona il 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 da eliminare.

5. Fai clic sul menu (tre puntini verticali) situato 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 servizio quando crei un trigger nei nuovi progetti. Per ulteriori informazioni, consulta Modifica dell'account di servizio predefinito di Cloud Build.

L'account di servizio configurato per un trigger di compilazione può fornire autorizzazioni elevate al momento della compilazione agli utenti che utilizzano gli trigger per invocare una compilazione. Questo si applica sia all'account di servizio predefinito di Cloud Build sia agli account di servizio specificati dall'utente. Tieni presente i seguenti aspetti implicazioni derivanti dall'utilizzo dei trigger di build:

• Un utente senza accesso al tuo progetto Cloud, ma con accesso in scrittura al repository associato agli trigger di compilazione nel progetto, avrà le autorizzazioni per modificare il codice in fase di compilazione.
• Se utilizzi i trigger per richieste di pull di GitHub, qualsiasi utente con accesso in lettura il repository può inviare una richiesta di pull, che potrebbe eseguire una build Include le modifiche al codice nella richiesta di pull. Per scoprire come disattiva questo comportamento per i trigger delle richieste di pull GitHub. Consulta la sezione Creazione di Trigger di GitHub.

È buona norma di sicurezza creare un account di servizio con solo i ruoli obbligatori per l'attivatore. Per saperne di più, consulta Configurare gli account di servizio specificati dall'utente. Per saperne di più sul servizio legacy di Cloud Build e le relative autorizzazioni associate, vedi Servizio Cloud Build Google Cloud.

Passaggi successivi

• Scopri come avviare le build manualmente o configurare 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.