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 le build automatiche sono chiamati trigger di build. Questi trigger possono contribuire a garantire che le immagini container siano sempre aggiornate. Puoi anche utilizzarli per creare e testare i rami delle funzionalità.

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

Utilizzo di un Dockerfile

Per utilizzare un Dockerfile per la configurazione di compilazione, devi specificare la directory Dockerfile e fornire un nome per l'immagine risultante. Per informazioni dettagliate 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 per la configurazione di compilazione, devi fornire la posizione di un file di configurazione della build.

Una volta impostata la posizione, 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 estratto solo il singolo commit che ha attivato una build automatica. Per saperne di più e scoprire come includere una parte maggiore della cronologia dei repository, consulta Clonazione non superficiale.

  • 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 Cloudcon cui stai lavorando. Questa autorizzazione viene in genere concessa tramite il ruolo cloudbuild.builds.editor.

    Quando configuri un trigger di build con un repository esterno per la prima volta, devi configurare l'autorizzazione con quel repository. Per ulteriori informazioni, vedi Aggiunta di un repository remoto.

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

  • Per informazioni su quote e limiti di 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 Trigger

  2. Seleziona il tuo 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 il trigger.

    • (Facoltativo) Descrizione: inserisci una descrizione del trigger.

    • Evento: seleziona l'evento del repository per richiamare il trigger.

      • Push a un ramo: imposta il trigger per avviare una build quando vengono eseguiti commit a un ramo specifico.

      • Push nuovo tag: imposta il trigger per avviare una build sui commit che contengono un tag specifico.

    • Origine: seleziona il repository e il ramo o il tag corrispondente in cui verificare la presenza di eventi.

      Quando viene eseguita la build, 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 compilazione.

      • Ramo o Tag: specifica un'espressione regolare con il valore del ramo o del tag da soddisfare. Le barre (/) non possono essere utilizzate nei tag. Per saperne di più sulla sintassi accettabile delle espressioni regolari, vedi 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 della build per la configurazione.
        • Dockerfile: utilizza un Dockerfile per la configurazione.
        • Buildpack: utilizza i buildpack per la configurazione.

      • Posizione: specifica la posizione 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 dei buildpack. 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 del 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 di ambiente e i valori di Buildpack. Per saperne di più sulle variabili di ambiente dei buildpack, consulta Variabili di ambiente.

        • Inline: 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 consoleGoogle Cloud utilizzando la sintassi YAML o JSON. Fai clic su Fine per salvare la configurazione della build.

    • Service account: seleziona il account di servizio da utilizzare quando richiami il trigger. Se non selezioni un account di servizio, viene utilizzato il service account 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 tuo repository su cui 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 (anteprima) è l'indirizzo email associato al tuo account di servizio. Se non includi questo flag, viene utilizzato il service account Cloud Build predefinito.
  • [Facoltativo] --require-approval è il flag da includere per configurare il trigger in modo che richieda l'approvazione.

Per un elenco completo dei flag, consulta il riferimento gcloud per scoprire 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 i 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, poi su Trigger Cloud Build.

Ignorare 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, utilizza il pulsante Esegui trigger.

Cloni non superficiali

Per creare l'origine in un repository Git, Cloud Source Repositories esegue una clonazione superficiale del repository. Quando Cloud Source Repositories esegue una clonazione superficiale, estrae dallo spazio di lavoro solo il singolo commit che ha attivato la build e poi la crea da questa origine. Cloud Source Repositories non estrae altri rami o la cronologia. Questa operazione viene eseguita per efficienza. Le build non vengono ritardate mentre Cloud Source Repositories recupera l'intero repository e la cronologia solo per eseguire la build da un singolo commit.

Per includere una parte maggiore della cronologia del repository nella build, aggiungi un passaggio di build nel file di configurazione di build per "annullare" la clonazione. Ad esempio:

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

Per maggiori informazioni su git fetch, consulta il riferimento di Git. Per istruzioni su come scrivere un file di configurazione della build, vedi Panoramica della configurazione della build.

Passaggi successivi