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

I trigger di build possono eseguire una build sulla base di un Dockerfile o di un file di configurazione della build.

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

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

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 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 parte maggiore della cronologia dei repository, consulta Annullamento della proprietà 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 il repository. Per ulteriori informazioni, consulta Aggiungere un repository come remoto.

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

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

Crea un trigger di build

Console

  1. Apri la pagina Attivatori 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 di attivazione:

    • 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 al ramo: imposta il trigger per avviare una build sui commit in un ramo specifico.

      • Esegui il push del 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 controllare 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 valore del ramo o del tag da associare. Nei tag non è possibile utilizzare le barre (/). Per ulteriori informazioni sulla sintassi accettabile delle espressioni regolari, consulta la sezione sintassi RE2.

    • Configurazione: seleziona il file di configurazione della build che si trova nel repository remoto o crea un file di configurazione di compilazione 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 buildpacks per la configurazione.

      • Posizione: specifica la località per la configurazione.

        • Repository: se il file di configurazione si trova nel 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 dalla tua build.
        • Variabili di ambiente Buildpack (facoltativo). 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 del 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 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 repository.
  • BRANCH_PATTERN è il nome del ramo nel repository per richiamare la build.
  • TAG_PATTERN è il nome del tag nel repository per 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 visualizzare 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 alcuna 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 nell'area di lavoro solo del commit che ha attivato la build, quindi esegue la build da questa origine. Cloud Source Repositories non esegue il check-out di altri rami o 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 creare da un singolo commit.

Per includere una quantità maggiore della cronologia del repository nella build, 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 ulteriori informazioni su git fetch, consulta la pagina relativa a riferimento git. Per istruzioni sulla scrittura di un file di configurazione di compilazione, consulta la pagina Panoramica della configurazione di build.

Passaggi successivi