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 connettersi a repository di origine come GitHub e Bitbucket e creare trigger di build per creare il codice nei repository.

Prima di iniziare

  • Attiva l'API Cloud Build.

    Abilita l'API

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

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 i trigger per i tuoi repository in Cloud Source Repositories senza connetterti manualmente a loro.

Se connetti un repository esterno, ad esempio uno ospitato su GitHub o Bitbucket, ti serviranno autorizzazioni a livello di amministratore per connettere inizialmente il repository a Cloud Build. 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.

  4. Fai clic su Connect Repository (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 codice sorgente, Cloud Build esegue il mirroring del repository in Cloud Source Repositories e lo utilizza 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, quindi fai clic su Connetti.

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

  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 o 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 di 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 alla regione 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.

      • Esegui il push a un ramo: imposta il trigger per avviare una build in base ai commit per 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 il trigger per avviare una build quando esegue il commit di una richiesta di pull.

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

      • 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, l'impostazione predefinita di lavoro per Cloud Build. Scopri di più sulle directory di lavoro Nella pagina di 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. L'organizzazione il criterio sostituisce il trigger e la build non viene eseguita. Per saperne di più, vedi La porta si basa sul criterio dell'organizzazione per il tuo progetto.

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

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

      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/. Se modifichi 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 repository su un ramo esistente, Cloud Build esamina i file modificati tra il commit appena eseguito il push e il commit a cui puntava il ramo 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 un creare.

    • 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 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 nella cartella repository remoto, fornisci la posizione file di configurazione della build, Dockerfile o la directory buildpacks. Se la configurazione della build è un Dockerfile o un buildpack, dovrai fornire un nome per l'immagine risultante e, facoltativamente, un timeout per creare. Dopo che hai fornito Dockerfile o buildpack nome dell'immagine, vedrai un'anteprima della docker build o pack che verrà eseguito dalla build.
        • (Facoltativo) Variabili di ambiente Buildpack: se buildpacks come tipo di configurazione, fai clic Aggiungi la variabile di ambiente del pacchetto per specificare il tuo buildpack variabili e valori di ambiente. 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 l'opzione di configurazione, puoi specificare la configurazione della build in linea. Fai clic su Apri editor per scrivere il file di configurazione della build nell' Console Google Cloud con la sintassi YAML o JSON. Fai clic su Fine per e salvare la configurazione della build.

    • 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 la nome risorsa del pool privato del modulo projects/WORKERPOOL_PROJECT_ID/locations/REGION/workerPools/WORKERPOOL_ID.

    • (Facoltativo) Variabili di sostituzione: se hai selezionato la colonna Cloud Build di configurazione come opzione di configurazione della build, puoi scegliere di definire specifiche di sostituzione 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 il deployment dell'app viene eseguito in un ambiente nella configurazione della build e poi utilizza questo campo per definire le variabili di sostituzione specificando nel quale deve essere eseguito il deployment del trigger. 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, l'impostazione predefinita Account di servizio Cloud Build .

  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 in su cui richiamare la build.

  • BUILD_CONFIG_FILE è il percorso della tua build di configurazione del deployment.

  • SERVICE_ACCOUNT è l'indirizzo email associato a al tuo account di servizio. Se non includi questo flag, il valore predefinito Account di servizio Cloud Build .

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

Per un elenco completo dei flag, consulta la documentazione di riferimento di gcloud su come creare gli 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 della filiale su cui richiamare la build.
  • TAG_PATTERN è il nome del tag in su cui richiamare la build.
  • BUILD_CONFIG_FILE è il percorso della tua build di configurazione del deployment.
  • SERVICE_ACCOUNT è l'indirizzo email associato a al tuo account di servizio. Se non includi questo flag, il valore predefinito Account di servizio Cloud Build .
  • [Facoltativo] --require-approval è il flag da includere per configurare l'attivatore per richiedere 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.

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

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

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

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 quando vogliamo richiamare una build. Ad esempio, potresti non voler richiamare una build quando devi aggiornare 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 il tuo codice sorgente su un repository Git, Cloud Build esegue una 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 è fatto per l'efficienza, in modo che le build non devono aspettare per recuperare l'intero repository e la cronologia solo per creare 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']
...

Per ulteriori informazioni su git fetch, consulta git riferimento. 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 entro il giorno 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 approvazione.

La build verrà avviata quando un utente con le autorizzazioni approva la build. A scopri di più sulle approvazioni di Cloud Build, La porta si basa sull'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 di 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.

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 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 di build

  2. Seleziona il tuo progetto dal menu a discesa del selettore progetti nella parte superiore di 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.

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 di build

  2. Seleziona il tuo progetto dal menu a discesa del selettore progetti nella parte superiore di 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

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

  • Un utente senza accesso al tuo progetto Cloud, ma con accesso in scrittura al associato ai trigger di build nel progetto avrà autorizzazioni per modificare il codice che stai creando.
  • 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.

Una buona prassi di sicurezza consiste nel creare un account di servizio solo ruoli per il trigger. Per scoprire di più, consulta Configura il servizio specificato dall'utente Google Cloud. Scopri di più sull'account di servizio Cloud Build e le autorizzazioni associate, vedi Servizio Cloud Build Google Cloud.

Passaggi successivi