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 da creare 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 attivatori possono contribuire a garantire che le immagini container siano sempre aggiornate. Puoi usarli anche per creare e testare rami di caratteristiche.

I trigger di build possono eseguire una build basata su un Dockerfile o su un file di configurazione di compilazione.

Utilizzo di un Dockerfile

Per utilizzare un Dockerfile per la configurazione della build, devi 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 fornito il Dockerfile e il nome dell'immagine, vedrai un'anteprima del comando docker build eseguito dalla build e un riepilogo della configurazione del trigger.

Utilizzo di un file di configurazione di compilazione

Per utilizzare un file di configurazione di compilazione, devi specificare il percorso di un file di configurazione di compilazione.

Una volta impostata la località, viene visualizzato 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 quantità maggiore della cronologia dei repository, consulta la pagina relativa all'annullamento dell'autorizzazione dei cloni.

  • Se utilizzi un altro provider Git ospitato, ad esempio 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. In genere questa autorizzazione viene concessa tramite il ruolo cloudbuild.builds.editor.

    Quando configuri per la prima volta un trigger di build con un repository esterno, devi configurare l'autorizzazione con quel repository. Per saperne di più, consulta Aggiungere un repository remoto.

    Dopo aver configurato il repository esterno, Cloud Source Repositories crea un mirroring 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 progetto dal 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 del 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.

      • Push a un ramo: imposta il trigger per avviare una build sui commit in un ramo specifico.

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

    • Origine: seleziona il repository e il ramo o tag corrispondente per verificare la presenza di 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 di creazione.

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

    • Configurazione: seleziona il file di configurazione della build che si trova nel repository remoto o crea un file di configurazione della build incorporato da utilizzare per la 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 tua configurazione.
        • Dockerfile: utilizza un Dockerfile per la configurazione.
        • Buildpack: utilizza i buildpack per la configurazione.

      • Località: specifica la località della configurazione.

        • Repository: se il file di configurazione si trova nel repository remoto, specifica il percorso del file di configurazione della build, della directory Dockerfile o della directory buildpacks. Se il tipo di configurazione della build è Dockerfile o un 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 buildpack per specificare le variabili e i valori di ambiente buildpack. Per scoprire di più sulle 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 di compilazione 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 per richiamare 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 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 su come creare 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 e poi su Trigger di Cloud Build.

Ignora un trigger di build

In alcuni casi, potrebbe essere opportuno modificare il codice sorgente, ma non 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, utilizza il pulsante Esegui trigger.

Eliminazione dei cloni

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, esegue il check-out dall'area di lavoro solo del commit che ha attivato la build, quindi crea da quell'origine. Cloud Source Repositories non esegue il check-out di altri rami o di cronologia. Questo avviene per una maggiore efficienza. Le build non subiscono ritardi mentre Cloud Source Repositories recupera l'intero repository e la cronologia solo per la creazione da un singolo commit.

Per includere nella build una quantità maggiore della cronologia del repository, aggiungi un passaggio di build nel file di configurazione della build per eliminare il clone. Ad esempio:

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

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

Passaggi successivi