Configurare le notifiche di BigQuery

Cloud Build può inviarti notifiche sugli aggiornamenti delle build a canali specifici, come Slack o il tuo server SMTP. Questa pagina spiega come configurare le notifiche utilizzando il notificatore BigQuery.

Il notificatore BigQuery ti consente di specificare i filtri per le build che vuoi archiviare nel database. Ad esempio, puoi raggruppare le build per ID trigger, tag o valori di sostituzione. Il notificatore BigQuery scrive anche i dati in BigQuery in un formato standardizzato che include campi calcolati non immediatamente accessibili nell'oggetto Build, come le dimensioni dell'immagine o la durata dell'esecuzione. Se vuoi scoprire come esportare le voci di log in BigQuery o in un'altra destinazione, consulta Esportare i log con la Google Cloud console.

Prima di iniziare

  • Abilita le API Cloud Build, Cloud Run, Pub/Sub e BigQuery.

    Ruoli richiesti per abilitare le API

    Per abilitare le API, devi disporre dell'autorizzazione serviceusage.services.enable. Se hai creato il progetto, probabilmente hai già questa autorizzazione tramite il ruolo Proprietario (roles/owner). In caso contrario, puoi ottenere questa autorizzazione tramite il ruolo Amministratore utilizzo servizi (roles/serviceusage.serviceUsageAdmin). Scopri come concedere i ruoli.

    Abilita le API

Configurazione delle notifiche di BigQuery

La sezione seguente spiega come configurare manualmente le notifiche HTTP utilizzando il notificatore BigQuery. Se preferisci automatizzare la configurazione, consulta Automatizzazione della configurazione per le notifiche.

Per configurare le notifiche di BigQuery:

  1. Concedi al account di servizio di Cloud Run l'autorizzazione per creare e scrivere tabelle BigQuery, l'autorizzazione per recuperare i dati di Artifact Registry relativi alla build e l'accesso in lettura e scrittura ai bucket Cloud Storage:

    1. Vai alla pagina IAM nella Google Cloud console:

      Apri la pagina IAM

    2. Individua il service account predefinito di Compute Engine associato al tuo progetto:

      Il service account predefinito di Compute Engine avrà un aspetto simile al seguente:

      PROJECT_NUMBER-compute@developer.gserviceaccount.com

    3. Fai clic sull'icona a forma di matita nella riga contenente il service account predefinito di Compute Engine. Verrà visualizzata la scheda Accesso in modifica.

    4. Fai clic su Aggiungi un altro ruolo.

    5. Aggiungi i seguenti ruoli:

      • Lettore Artifact Registry
      • Editor dati BigQuery
      • Visualizzatore oggetti Storage

      Il ruolo Lettore Artifact Registry ti consente di recuperare i dati per le immagini. Il ruolo Editor dati BigQuery ti consente di accedere in lettura e scrittura ai dati. Il ruolo Visualizzatore oggetti Storage ti consente di accedere in lettura agli oggetti Cloud Storage.

    6. Fai clic su Salva.

  2. Scrivi un file di configurazione del notificatore per configurare il notificatore BigQuery e filtrare gli eventi di build:

    Nel seguente file di configurazione del notificatore di esempio, il campo filter utilizza Common Expression Language con la variabile build per filtrare gli eventi di build con un ID trigger specificato:

    apiVersion: cloud-build-notifiers/v1
kind: BigQueryNotifier
metadata:
  name: example-bigquery-notifier
spec:
  notification:
    filter: build.build_trigger_id == "123e4567-e89b-12d3-a456-426614174000"
    params:
      buildStatus: $(build.status)
    delivery:
      table: projects/PROJECT_ID/datasets/DATASET_NAME/tables/TABLE_NAME
    template:
      type: golang
      uri: gs://BUCKET_NAME/bq.json

    Dove:

    • buildStatus è un parametro definito dall'utente. Questo parametro assume il valore di ${build.status}, lo stato della build.
    • BUCKET_NAME è il nome del bucket.
    • PROJECT_ID è l'ID del tuo Google Cloud progetto.
    • DATASET_NAME è il nome che vuoi assegnare al set di dati.
    • TABLE_NAME è il nome che vuoi assegnare alla tabella.

    • Il campo uri fa riferimento al file bq.json. Questo file fa riferimento a un modello JSON ospitato in Cloud Storage e rappresenta le informazioni da inserire nella tabella BigQuery.

    Per visualizzare un esempio di file modello, consulta il bq.json file nel repository cloud-build-notifiers-repository.

    Il valore TABLE_NAME nel file di configurazione del notificatore può fare riferimento a:

    • Una tabella inesistente
    • Una tabella vuota senza schema

    • Una tabella esistente con uno schema che corrisponde alle specifiche dello schema nel notificatore BigQuery

    Ti consigliamo di specificare l'ID trigger di build come filtro, perché ti consente di correlare i dati di build per i trigger. Puoi anche specificare più ID trigger in un elenco: build.build_trigger_id in ["example-id-123", "example-id-456"].

    Per ottenere l'ID trigger, esegui il seguente comando, dove TRIGGER_NAME è il nome del trigger:

    gcloud builds triggers describe TRIGGER_NAME

    Il comando elencherà i campi associati al trigger, incluso l'ID trigger.

    Per visualizzare l'esempio, consulta il file di configurazione del notificatore per il notificatore BigQuery.

    Per altri campi in base ai quali puoi filtrare, consulta la risorsa Build. Per altri esempi di filtro, consulta Utilizzo di CEL per filtrare gli eventi di build.

  3. Carica il file di configurazione del notificatore in un bucket Cloud Storage:

    1. Se non hai un bucket Cloud Storage, esegui il seguente comando per crearne uno, dove BUCKET_NAME è il nome che vuoi assegnare al bucket, soggetto ai requisiti di denominazione.

      gcloud storage buckets create gs://BUCKET_NAME/

    2. Carica il file di configurazione del notificatore nel bucket:

      gcloud storage cp CONFIG_FILE_NAME gs://BUCKET_NAME/CONFIG_FILE_NAME

      Dove:

      • BUCKET_NAME è il nome del bucket.
      • CONFIG_FILE_NAME è il nome del file di configurazione del notificatore.

  4. Esegui il deployment del notificatore in Cloud Run:

     gcloud run deploy SERVICE_NAME \
   --image=us-east1-docker.pkg.dev/gcb-release/cloud-build-notifiers/bigquery:latest \
   --no-allow-unauthenticated \
   --update-env-vars=CONFIG_PATH=CONFIG_PATH,PROJECT_ID=PROJECT_ID

    Dove:

    • SERVICE_NAME è il nome del servizio Cloud Run in cui stai eseguendo il deployment dell'immagine.
    • CONFIG_PATH è il percorso del file di configurazione del notificatore per il notificatore BigQuery, gs://BUCKET_NAME/CONFIG_FILE_NAME.
    • PROJECT_ID è l'ID del tuo Google Cloud progetto.

    Il comando gcloud run deploy esegue il pull dell'ultima versione dell'immagine ospitata da Artifact Registry di proprietà di Cloud Build. Cloud Build supporta le immagini dei notificatori per nove mesi. Dopo nove mesi, Cloud Build elimina la versione dell'immagine. Se vuoi utilizzare una versione precedente dell'immagine, devi specificare la versione semantica completa del tag dell'immagine nell'attributo image del comando gcloud run deploy. Le versioni e i tag delle immagini precedenti sono disponibili in Artifact Registry.

  5. Crea un account di servizio per rappresentare l'identità della sottoscrizione Pub/Sub:

    gcloud iam service-accounts create SUB_IDENTITY_SERVICE_ACCOUNT \
  --display-name "SUB_IDENTITY_SERVICE_ACCOUNT_DISPLAY_NAME"

    Dove:

    • SUB_IDENTITY_SERVICE_ACCOUNT è un nome per il account di servizio.

    • SUB_IDENTITY_SERVICE_ACCOUNT_DISPLAY_NAME è un nome visualizzato per il account di servizio.

  6. Concedi al account di servizio di identità della sottoscrizione Pub/Sub le autorizzazioni necessarie per creare token di autenticazione nel tuo Google Cloud progetto.

    gcloud iam service-accounts add-iam-policy-binding \
    SUB_IDENTITY_SERVICE_ACCOUNT@PROJECT_ID.iiam.gserviceaccount.com \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com \
    --role=roles/iam.serviceAccountTokenCreator

    Dove:

    • PROJECT_ID è l'ID del tuo Google Cloud progetto.

    • PROJECT_NUMBER è il numero del tuo progetto Google Cloud .

  7. Concedi al account di servizio SUB_IDENTITY_SERVICE_ACCOUNT il ruolo Invoker di Cloud Run:

    gcloud run services add-iam-policy-binding SERVICE_NAME \
   --member=serviceAccount:SUB_IDENTITY_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com \
   --role=roles/run.invoker

    Dove:

    • SERVICE_NAME è il nome del servizio Cloud Run in cui stai eseguendo il deployment dell'immagine.

    • PROJECT_ID è l'ID del tuo Google Cloud progetto.

  8. Crea l'argomento cloud-builds per ricevere i messaggi di aggiornamento della build per il notificatore:

    gcloud pubsub topics create cloud-builds

    Puoi anche definire un nome argomento personalizzato nel file di configurazione della build in modo che i messaggi vengano inviati all'argomento personalizzato. In questo caso, devi creare un argomento con lo stesso nome argomento personalizzato:

    gcloud pubsub topics create topic-name

    Per scoprire di più, consulta Argomenti Pub/Sub per le notifiche di build.

  9. Crea un sottoscrittore push Pub/Sub per il notificatore:

     gcloud pubsub subscriptions create subscriber-id \
       --topic=cloud-builds \
       --push-endpoint=SERVICE_URL \
       --push-auth-service-account=SUB_IDENTITY_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com

Dove: + SUBSCRIBER_ID è il nome che vuoi assegnare alla sottoscrizione. + SERVICE_URL è l'URL generato da Cloud Run per il nuovo servizio. + PROJECT_ID è l'ID del tuo Google Cloud progetto.

Note: By default, [subscriptions expire after 31 days of inactivity](/pubsub/docs/subscription-overview#lifecycle).
You can adjust or disable the expiration period by including the
[`--expiration-period` flag](/sdk/gcloud/reference/pubsub/subscriptions/create#--expiration-period)
when creating the subscription.

Le notifiche per il tuo progetto Cloud Build sono ora configurate.

La prossima volta che richiami una build, la tabella verrà aggiornata con i dati più recenti che corrispondono al filtro configurato per il notificatore BigQuery.

Visualizzazione dei dati di build

Per visualizzare i dati di build in BigQuery:

  1. Apri la pagina della console BigQuery:

    Apri la pagina BigQuery

  2. In Risorse, fai clic sull'ID progetto che utilizzi per configurare il tuo notificatore BigQuery.

  3. Fai clic sul nome del set di dati.

  4. Fai clic sul nome della tabella.

Ora puoi visualizzare le informazioni relative alla tabella, incluso lo schema e un'anteprima dei dati di build elencati nella tabella.

Accesso ai dati di build

Puoi eseguire query sui dati nella tabella utilizzando lo strumento a riga di comando bq o la console BigQuery.

CLI

Per eseguire query sui dati nella tabella utilizzando lo strumento a riga di comando bq, esegui il seguente comando nel terminale, dove SQL_QUERY è la query:

bq query SQL_QUERY

Se prevedi di utilizzare gli esempi di query in questa pagina, assicurati di specificare il --nouse_legacy_sql flag nel comando. Lo strumento a riga di comando bq utilizza SQL legacy, mentre le query di esempio no. Esegui il seguente comando nel terminale per eseguire query sui dati senza SQL legacy:

bq query SQL_QUERY --nouse_legacy_sql

Console

Per eseguire query sui dati nella tabella utilizzando la console BigQuery:

  1. Apri la pagina della console BigQuery:

    Apri la pagina BigQuery

  2. In Risorse, fai clic sul nome della tabella su cui vuoi eseguire la query.

  3. Scrivi la query SQL nell'editor di query.

Utilizzo delle query per accedere ai dati di build

Le seguenti query di esempio mostrano come accedere ai dati di build per l'evento di build, dopo la configurazione del notificatore BigQuery:

Cronologia generale delle build

SELECT * FROM `projectID.datasetName.tableName`

Conteggio delle build raggruppate per stato

SELECT STATUS, COUNT(*)
FROM `projectID.datasetName.tableName`
GROUP BY STATUS

Frequenza di deployment giornaliera per la settimana corrente

SELECT DAY, COUNT(STATUS) AS Deployments
FROM (SELECT DATETIME_TRUNC(CreateTime, WEEK) AS WEEK,
      DATETIME_TRUNC(CreateTime, DAY) AS DAY,
      STATUS
      FROM `projectID.datasetName.tableName`
      WHERE STATUS="SUCCESS")
WHERE WEEK = DATETIME_TRUNC(CURRENT_DATETIME(), WEEK)
GROUP BY DAY

Per visualizzare altre query di esempio, consulta il file README del notificatore BigQuery di Cloud Build nel repository cloud-build-notifiers su GitHub. Per scoprire di più su come eseguire query sui dati utilizzando BigQuery, consulta Eseguire query e visualizzare i dati.

Utilizzo di CEL per filtrare gli eventi di build

Cloud Build utilizza CEL con la variabile build nei campi elencati nella risorsa Build per accedere ai campi associati all'evento di build, come l'ID trigger, l'elenco delle immagini o i valori di sostituzione. Puoi utilizzare la filter stringa per filtrare gli eventi di build nel file di configurazione della build utilizzando qualsiasi campo elencato nella risorsa Build. Per trovare la sintassi esatta associata al campo, consulta il cloudbuild.proto file.

Filtro per ID trigger

Per filtrare in base all'ID trigger, specifica il valore dell'ID trigger nel campo filter utilizzando build.build_trigger_id, dove trigger-id è l'ID trigger come stringa:

filter: build.build_trigger_id == trigger-id

Filtro per stato

Per filtrare in base allo stato, specifica lo stato della build in base al quale vuoi filtrare nel campo filter utilizzando build.status.

L'esempio seguente mostra come filtrare gli eventi di build con lo stato SUCCESS utilizzando il campo filter:

filter: build.status == Build.Status.SUCCESS

Puoi anche filtrare le build con stati diversi. L'esempio seguente mostra come filtrare gli eventi di build con lo stato SUCCESS, FAILURE o TIMEOUT utilizzando il campo filter:

filter: build.status in [Build.Status.SUCCESS, Build.Status.FAILURE, Build.Status.TIMEOUT]

Per visualizzare altri valori di stato in base ai quali puoi filtrare, consulta Stato nella documentazione di riferimento della risorsa Build.

Filtro per tag

Per filtrare in base al tag, specifica il valore del tag nel campo filter utilizzando build.tags, dove tag-name è il nome del tag:

filter: tag-name in build.tags

Puoi filtrare in base al numero di tag specificati nell'evento di build utilizzando size. Nell'esempio seguente, il campo filter filtra gli eventi di build che hanno esattamente due tag specificati, con un tag specificato come v1:

filter: size(build.tags) == 2 && "v1" in build.tags

Filtro per immagini

Per filtrare in base alle immagini, specifica il valore dell'immagine nel campo filter utilizzando build.images, dove image-name è il nome completo dell'immagine come elencato in Artifact Registry, ad esempio us-east1-docker.pkg.dev/my-project/docker-repo/image-one:

filter: image-name in build.images

Nell'esempio seguente, il campo filter filtra gli eventi di build che hanno us-east1-docker.pkg.dev/my-project/docker-repo/image-one o us-east1-docker.pkg.dev/my-project/docker-repo/image-two specificati come nomi delle immagini:

filter: "us-east1-docker.pkg.dev/my-project/docker-repo/image-one" in build.images || "us-east1-docker.pkg.dev/my-project/docker-repo/image-one" in build.images

Filtro per ora

Puoi filtrare gli eventi di build in base all'ora di creazione, all'ora di inizio o all'ora di fine di una build specificando una delle seguenti opzioni nel campo filter: build.create_time, build.start_time o build.finish_time.

Nell'esempio seguente, il campo filter utilizza timestamp per filtrare gli eventi di build con un'ora di richiesta per creare la build il 20 luglio 2020 alle 06:00:

filter: build.create_time == timestamp("2020-07-20:T06:00:00Z")

Puoi anche filtrare gli eventi di build in base ai confronti temporali. Nell'esempio seguente, il campo filter utilizza timestamp per filtrare gli eventi di build con un'ora di inizio compresa tra il 20 luglio 2020 alle 06:00 e il 30 luglio 2020 alle 06:00.

filter: timestamp("2020-07-20:T06:00:00Z") >= build.start_time && build.start_time <= timestamp("2020-07-30:T06:00:00Z")

Per scoprire di più su come vengono espressi i fusi orari in CEL, consulta la definizione del linguaggio per i fusi orari.

Per filtrare in base alla durata di una build, puoi utilizzare duration per confrontare i timestamp. Nell'esempio seguente, il campo filter utilizza duration per filtrare gli eventi di build con build che vengono eseguite per almeno cinque minuti:

filter: build.finish_time - build.start_time >= duration("5m")

Filtro per sostituzione

Puoi filtrare in base alla sostituzione specificando la variabile di sostituzione nel campo filter utilizzando build.substitutions. Nell'esempio seguente, il campo filter elenca le build che contengono la variabile di sostituzione substitution-variable e verifica se substitution-variable corrisponde al valore di sostituzione specificato substitution-value:

filter: build.substitutions[substitution-variable] == substitution-value

Dove:

  • substitution-variable è il nome della variabile di sostituzione.
  • substitution-value è il nome del valore di sostituzione.

Puoi anche filtrare in base ai valori delle variabili di sostituzione predefinite. Nell'esempio seguente, il campo filter elenca le build con il nome del ramo master e le build con il nome del repository github.com/user/my-example-repo. Le variabili di sostituzione predefinite BRANCH_NAME e REPO_NAME vengono passate come chiavi a build.substitutions:

filter: build.substitutions["BRANCH_NAME"] == "master" && build.substitutions["REPO_NAME"] == "github.com/user/my-example-repo"

Se vuoi filtrare le stringhe utilizzando le espressioni regolari, puoi utilizzare la funzione integrata matches. Nell'esempio seguente, il campo filter filtra le build con lo stato FAILURE o TIMEOUT e che hanno anche una variabile di sostituzione della build TAG_NAME con un valore che corrisponde all'espressione regolare v{DIGIT}.{DIGIT}.{3 DIGITS}).

filter: build.status in [Build.Status.FAILURE, Build.Status.TIMEOUT] && build.substitutions["TAG_NAME"].matches("^v\\d{1}\\.\\d{1}\\.\\d{3}$")

Per visualizzare un elenco dei valori di sostituzione predefiniti, consulta Utilizzo delle sostituzioni predefinite.

Passaggi successivi