Automazione delle build con Cloud Build

Questo argomento descrive come automatizzare le build utilizzando Cloud Build e Cloud Source Repositories.

Puoi configurare Cloud Build in modo che crei automaticamente una nuova immagine ogni volta che un utente esegue il push di una modifica ai file archiviati in Cloud Source Repositories. Gli eventi che avviano build automatiche sono chiamati trigger di build. Questi trigger possono contribuire a garantire che le immagini container siano sempre aggiornate. Puoi usarle anche per creare e testare rami di caratteristiche.

I trigger di build possono eseguire una build in base a un Dockerfile o a un file di configurazione di compilazione.

Utilizzo di un Dockerfile

Per utilizzare un Dockerfile per la configurazione di compilazione, dovrai specificare la directory Dockerfile e fornire un nome per l'immagine risultante. Per maggiori dettagli sulla creazione di Dockerfile, consulta la documentazione di Docker.

Dopo aver specificato il Dockerfile e il nome dell'immagine, vedrai un'anteprima del comando docker build eseguito dalla tua build e un riepilogo della configurazione del trigger.

Utilizzo di un file di configurazione di compilazione

Per utilizzare un file di configurazione della build, devi fornire il percorso di un file di configurazione della build.

Una volta impostata la località, vedrai un riepilogo dell'attivatore.

Prima di iniziare

Informazioni aggiuntive

  • I trigger di build utilizzano cloni superficiali di un repository. Con i cloni superficiali, nell'area di lavoro viene eseguito il check-out solo del singolo commit che ha attivato una build automatica. Per ulteriori informazioni e per scoprire come includere una maggiore quantità di cronologia dei repository, consulta cloni non irregolari.

  • Se utilizzi un altro provider Git ospitato, ad esempio su GitHub o Bitbucket, e devi comunque eseguire il mirroring del repository in Cloud Source Repositories, devi disporre dell'autorizzazione cloudbuilds.builds.create per il progetto Google Cloud con cui stai lavorando. Questa autorizzazione in genere viene concessa tramite il ruolo di cloudbuild.builds.editor.

    Quando configuri per la prima volta un trigger di build con un repository esterno, devi configurare l'autorizzazione con il repository. Per ulteriori informazioni, consulta Aggiungere un repository come repository remoto.

    Dopo aver configurato il repository esterno, Cloud Source Repositories crea un mirror del repository.

  • Per informazioni su quote e limiti per Cloud Build, consulta Quote e limiti nella documentazione di Cloud Build.

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

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

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

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

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

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

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

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

gcloud

Esegui questo comando:

    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 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 (anteprima) è 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 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.

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

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

Visualizza trigger di build

Per visualizzare i trigger nella console Google Cloud, apri la pagina Trigger di Cloud Build.

Per visualizzare i trigger per un determinato progetto in Cloud Source Repositories, fai clic su Impostazioni in alto a destra, quindi su Trigger di Cloud Build.

Ignora un trigger di build

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

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

Ad esempio:

Author: A User <auser@example.com>
Date:   Tue Apr 3 12:03:35 2018 -0700

Fixed customer affecting issue. [skip ci]

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

Cloni non superficiali

Per creare il codice sorgente in un repository Git, Cloud Source Repositories esegue un clone superficiale del repository. Quando Cloud Source Repositories esegue un clone superficiale, rileva dall'area di lavoro solo il singolo commit che ha attivato la build, quindi crea da quell'origine. Cloud Source Repositories non esegue il check-out di altri rami o di altre cronologia. Questo è fatto per l'efficienza. Le build non subiscono ritardi mentre Cloud Source Repositories recupera l'intero repository e la cronologia solo per creare da un singolo commit.

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

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

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

Passaggi successivi