Creazione e gestione dei trigger di build

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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 codice sorgente 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

  • Per creare i trigger, devi avere il ruolo Editor Cloud Build (roles/cloudbuild.builds.editor).
  • Hai bisogno del codice sorgente in Cloud Source Repositories, GitHub o Bitbucket.
  • Devi avere un Dockerfile o un file di configurazione Cloud Build.

Connessione ai repository di origine

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

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

Completa i seguenti passaggi per connetterti a GitHub o Bitbucket:

  1. Apri la pagina Trigger in Google Cloud Console.

    Apri la pagina degli attivatori

  2. Seleziona il progetto e fai clic su Apri.

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

  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 relative operazioni.

  6. Fai clic su Continua.

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

  8. Nell'elenco dei repository disponibili, seleziona il repository desiderato, quindi fai clic su Connetti.

    Per i repository esterni, come GitHub e Bitbucket, devi disporre delle autorizzazioni a livello di proprietario per il progetto 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 in Google Cloud Console.

    Apri la pagina Trigger

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

  3. Fai clic su Apri.

  4. Fai clic su Crea trigger.

  5. Inserisci le seguenti impostazioni di attivazione:

    • Nome: inserisci un nome per l'attivatore.

    • Area geografica: seleziona l'area geografica per l'attivatore.

      Se il file di configurazione della build associato al trigger specifica un pool privato, la regione selezionata per il trigger deve corrispondere a quella del pool privato.

      Se selezioni global come area geografica, 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 di compilazione, oppure 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 al ramo: imposta il trigger per avviare una build sui commit in un ramo specifico.

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

      • Richiesta di pull (Cloud Source Repositories non supportato): imposta il trigger per avviare una build su commit su una richiesta di pull. Questa funzionalità è disponibile solo se crei un trigger GitHub. Per informazioni su come creare un trigger dell'app GitHub, consulta la sezione Creazione di trigger GitHub.

    • Origine: seleziona il repository e il ramo o il tag corrispondente da monitorare per gli eventi.

      • Repository: dall'elenco dei repository disponibili, seleziona il repository desiderato. Per connettere un nuovo repository, consulta la sezione Connessione ai repository di origine.
      • Ramo o Tag: specifica un'espressione regolare con il valore del ramo o del tag da soddisfare. Non è possibile utilizzare le barre (/) nei tag. Per ulteriori informazioni sulla sintassi accettabile delle espressioni regolari, consulta la sintassi RE2.

        Durante l'esecuzione della build, Cloud Build copia i contenuti del tuo repository in /workspace, la directory di lavoro predefinita per Cloud Build. Scopri di più sulle directory di lavoro nella pagina di riepilogo della configurazione di compilazione.

        Per consentire solo le build provenienti da origini specifiche, imposta un criterio dell'organizzazione per le integrazioni consentite (constraints/cloudbuild.allowedIntegrations) per negare l'interazione con l'origine definita nell'attivatore. Il criterio dell'organizzazione sostituisce il trigger e la build non viene eseguita. Per scoprire di più, consulta Gate build on policy dell'organizzazione per il tuo progetto.

    • (Facoltativo) File inclusi: 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 i caratteri supportati da Go Match, ** e l'alternativa.

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

      Se specifichi un file sia in File inclusi che in File ignorati, le modifiche al file non richiamano una build. Supponiamo di specificare **/README.md in File ignorati per ignorare README.md in qualsiasi directory e di specificare **/README.md in File inclusi per avviare una build nelle modifiche a qualsiasi file della cartella src/. Se apporti una modifica a src/README.md, Cloud Build non avvia una build. Ogni volta che esegui il push di una modifica nell'origine, Cloud Build esamina i file modificati per individuare quelli 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 e il commit a cui puntava il ramo.
      • Se il tuo repository è Cloud Source Repository e esegui il push di una modifica in un ramo appena creato, Cloud Build tratta tutti i file nel repository come file modificati.
      • Se elimini un ramo, Cloud Build non avvia una build.
    • Configurazione: seleziona il file di configurazione della build situato nel repository remoto o crea un file di configurazione della build 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.
        • Buildpack: utilizza i buildpack per la configurazione.
      • Località: specifica la posizione della configurazione.

        • Repository: se il file di configurazione si trova nel tuo repository remoto, fornisci la posizione del file di configurazione della build, della directory Dockerfile o della directory buildpacks. Se il tipo di configurazione della build è Dockerfile o un buildpack, dovrai 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.
        • (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 ulteriori informazioni sulle variabili di ambiente buildpack, consulta Variabili di ambiente.
        • In linea: se hai selezionato File di configurazione Cloud Build (yaml o json) come opzione di configurazione, puoi specificare la configurazione di build in linea. Fai clic su Apri editor per scrivere il file di configurazione della build in Google Cloud Console utilizzando la sintassi YAML o JSON. Fai clic su Fine per salvare la configurazione della build.

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

    • Pool privato: se hai selezionato Utilizza pool privato, specifica il nome della risorsa del pool privato del 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 le variabili di sostituzione specifiche per il 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 il deployment dell'app in un ambiente nel file di configurazione della build, quindi utilizzare questo campo per definire le variabili di sostituzione che specificano in quale ambiente deve essere eseguito il deployment di questo trigger. Per informazioni sulla specifica dei valori di sostituzione nei file di configurazione della build, consulta Sostituzione dei valori delle variabili.

    • (Facoltativo) Approvazione: seleziona la casella per richiedere l'approvazione prima di eseguire la build.

    • Account di servizio: seleziona l'account di servizio da utilizzare durante la chiamata al trigger. Se non selezioni un account di servizio, viene utilizzato l'account di servizio Cloud Build predefinito.

  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 beta 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 per richiamare la build.
  • TAG_PATTERN è il nome del tag nel tuo repository per 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, viene utilizzato l'account di servizio Cloud Build predefinito.

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

Per un elenco completo dei flag, consulta il riferimento gcloud su come creare trigger per Cloud Source Repositories.

Per creare un trigger se il codice sorgente è in GitHub:

    gcloud beta 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 è l'area geografica del tuo attivatore.
  • 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 per richiamare la build.
  • TAG_PATTERN è il nome del tag nel tuo repository per 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, viene utilizzato l'account di servizio Cloud Build predefinito.
  • [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 visualizzare i log di build dei tuoi repository. Questo flag è supportato per le build dai repository GitHub e GitHub Enterprise.

Per un elenco completo dei flag, consulta la documentazione di riferimento per gcloud su come creare 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

Test di un trigger di build

Per testare manualmente un trigger di build:

  1. Apri la pagina Trigger in Google Cloud Console.

    Apri la pagina degli attivatori

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

Ignorare un trigger di build

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

In questi casi, 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, utilizza il pulsante Esegui trigger nella pagina Trigger.

Includere la cronologia del repository in una build

Per creare l'origine su un repository Git, Cloud Build esegue un clone poco profondo del repository. Ciò significa che solo il singolo commit che ha avviato la build viene eseguito nell'area di lavoro per la creazione. Cloud Build non controlla altri rami o cronologia. Questo viene fatto in modo efficiente, 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 di più nella cronologia del repository nella build, aggiungi un passaggio di build nel file di configurazione della build per "unshallow" il clone. Ad esempio:

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

Per maggiori informazioni su git fetch, consulta la documentazione di riferimento. Per istruzioni sulla scrittura di un file di configurazione della build, consulta la panoramica della configurazione di build.

Reinvio della build per l'approvazione in corso...

Se la tua build è stata rifiutata, puoi inviarla di nuovo per sottoporla ad approvazione seguendo questi passaggi in Google Cloud Console:

  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 per l'approvazione.

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

La build inizia quando un utente con autorizzazioni approva la tua build. Per scoprire di più sulle approvazioni di Cloud Build, consulta Gate build on approval.

Aggiornamento di un trigger di build

console

  1. Apri la pagina Trigger in Google Cloud Console.

    Apri la pagina Trigger di build

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

  3. Fai clic su Apri.

  4. Individua la riga con il trigger che vuoi aggiornare.

  5. Fai clic sul menu (i tre punti verticali), posizionato all'estremità destra della riga.

  6. Seleziona Modifica.

gcloud

Per aggiornare un trigger:

  1. Esporta il trigger che vuoi aggiornare:

     gcloud beta builds triggers export TRIGGER_NAME --destination=EXPORT_PATH
    

    Dove:

    • TRIGGER_NAME è il nome del tuo attivatore.
    • 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 il trigger 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 il trigger:

     gcloud beta builds triggers import --source=IMPORT_PATH
    

    Dove:

    • IMPORT_PATH è il percorso file del trigger che vuoi importare.

Il trigger di build è stato aggiornato.

Disabilitazione di un trigger di build

console

  1. Apri la pagina Trigger in Google Cloud Console.

    Apri la pagina Trigger di build

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

  3. Fai clic su Apri.

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

  5. Fai clic sul menu (i tre punti verticali), posizionato all'estremità destra della riga.

  6. Seleziona Disable (Disattiva).

gcloud

Per disattivare un attivatore:

  1. Esporta il trigger che vuoi disattivare:

     gcloud beta builds triggers export TRIGGER_NAME --destination=EXPORT_PATH
    

    Dove:

    • TRIGGER_NAME è il nome del tuo attivatore.
    • 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 il trigger 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 il trigger:

     gcloud beta builds triggers import --source=IMPORT_PATH
    

    Dove:

    • IMPORT_PATH è il percorso file del trigger che vuoi importare.

Il trigger di build è ora disattivato.

La disattivazione di un attivatore non lo elimina. Per eliminare un trigger, consulta la pagina 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 in Google Cloud Console.

    Apri la pagina Trigger di build

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

  3. Fai clic su Apri.

  4. Individua la riga con il trigger che vuoi eliminare.

  5. Fai clic sul menu (i tre punti verticali), posizionato all'estremità destra della riga.

  6. Seleziona Elimina.

gcloud

Per eliminare un trigger, esegui questo comando:

  gcloud beta builds triggers delete TRIGGER_NAME

Dove:

  • TRIGGER_NAME è il nome del tuo attivatore.

Per un elenco completo dei flag, consulta la documentazione di riferimento per gcloud su come eliminare i trigger.

Implicazioni per la sicurezza dei trigger di build

I trigger di build utilizzano l'account Cloud Build per eseguire le build, che potrebbe fornire autorizzazioni in fase di build agli utenti che utilizzano trigger per eseguire una build. Quando utilizzi i trigger di build, tieni presente le seguenti implicazioni per la sicurezza:

  • Un utente senza accesso al tuo 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 di richiesta di pull di GitHub, qualsiasi utente con accesso in lettura al repository può inviare una richiesta di pull, che può eseguire una build che include modifiche al codice nella richiesta di pull. Per informazioni su come disattivare questo comportamento per i trigger di richiesta pull di GitHub, consulta la sezione Creazione di trigger di GitHub.

Per saperne di più sull'account di servizio Cloud Build e sulle autorizzazioni associate, consulta Account di servizio Cloud Build.

Passaggi successivi