Automazione delle build con Cloud Build

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

Puoi configurare Cloud Build in modo che crei automaticamente una nuova immagine 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 le immagini container siano sempre aggiornate. Puoi anche utilizzarle per creare testare i rami delle caratteristiche.

I trigger di build possono eseguire una build in base a un Dockerfile o a una build di configurazione del deployment.

Utilizzo di un Dockerfile

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

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

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 cloni superficiali viene eseguito il check-out solo del commit che ha attivato una build automatica. nell'area di lavoro. Per ulteriori informazioni e per scoprire come includere più dettagli cronologia dei repository, consulta l'articolo Unshallowing cloni.

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

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

    Dopo aver configurato il repository esterno, Cloud Source Repositories e 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 di 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 base ai commit per un determinato ramo.

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

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

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

      • Ramo o Tag: specifica un'espressione regolare con il ramo o valore del tag da far corrispondere. 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 della build che si trova in repository remoto o creare un file di configurazione di compilazione incorporato 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 nella cartella repository remoto, fornisci la posizione file di configurazione della build, Dockerfile o la directory buildpacks. Se la configurazione della build è un Dockerfile o un buildpack, dovrai fornire un nome per l'immagine risultante e, facoltativamente, un timeout per creare. Dopo che hai fornito Dockerfile o buildpack nome dell'immagine, vedrai un'anteprima della docker build o pack che verrà eseguito dalla build.
        • (Facoltativo) Variabili di ambiente Buildpack: se buildpacks come tipo di configurazione, fai clic Aggiungi la variabile di ambiente del pacchetto per specificare il tuo buildpack variabili e valori di ambiente. Per scoprire di più su Variabili di ambiente buildpack, consulta Variabili di ambiente.

        • In linea: se hai selezionato File di configurazione di Cloud Build (yaml o json) come l'opzione di configurazione, puoi specificare la configurazione della build in linea. Fai clic su Apri editor per scrivere il file di configurazione della build nell' Console Google Cloud con la sintassi YAML o JSON. Fai clic su Fine per e salvare la configurazione della build.

    • Account di servizio: seleziona l'account di servizio da utilizzare durante la chiamata il trigger. Se non selezioni un account di servizio, l'impostazione predefinita Account di servizio Cloud Build .

  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 della filiale su cui richiamare la build.
  • TAG_PATTERN è il nome del tag in su cui richiamare la build.
  • BUILD_CONFIG_FILE è il percorso della tua build di configurazione del deployment.
  • SERVICE_ACCOUNT (anteprima) è l'indirizzo email associato al tuo account di servizio. Se non lo includi il flag predefinito per l'account di servizio Cloud Build .
di Gemini Advanced.
  • [Facoltativo] --require-approval è il flag da includere per configurare l'attivatore per richiedere l'approvazione.

Per un elenco completo dei flag, consulta la documentazione di riferimento di gcloud su come creare gli attivatori per Cloud Source Repositories.

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

  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 Cloud Build Pagina Trigger.

Per visualizzare i trigger per un determinato progetto in Cloud Source Repositories, fai clic su Impostazioni in In alto a destra, poi fai clic 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 la 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, usa il pulsante Esegui trigger.

Cloni non superficiali

Per creare il tuo codice sorgente su un repository Git, Cloud Source Repositories esegue una clone superficiale del repository. Quando Cloud Source Repositories esegue clone superficiale, esce dall'area di lavoro solo il singolo commit ha attivato la build, per poi compilarla 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 Cloud Source Repositories recupera l'intero repository e la cronologia solo a partire da un singolo commit.

Per includere più cronologia del repository nella build, aggiungi una build del file di configurazione della build su "unshallow" il clone. Ad esempio:

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

Per ulteriori informazioni su git fetch, vedi Riferimento Git. Per istruzioni su come scrivere un file di configurazione di compilazione, vedi Panoramica della configurazione di compilazione.

Passaggi successivi