Configurazione delle notifiche Slack

Cloud Build può inviarti notifiche in merito agli aggiornamenti delle build inviando le notifiche ai canali desiderati, come Slack o il server SMTP. In questa pagina viene spiegato come configurare le notifiche utilizzando il Notificatore Slack.

Prima di iniziare

  • Abilita le API Cloud Build, Compute Engine, Cloud Run, Pub/Sub, and Secret Manager.

    Abilita le API

Configurazione delle notifiche Slack

La sezione seguente spiega come configurare manualmente le notifiche Slack utilizzando il Notificatore Slack. Se vuoi automatizzare la configurazione, consulta l'articolo sull'automazione della configurazione per le notifiche.

Per configurare le notifiche Slack:

  1. Crea un'app Slack per l'area di lavoro Slack desiderata.

  2. Attiva i webhook in arrivo per pubblicare messaggi da Cloud Build a Slack.

  3. Accedi all'app Slack per trovare l'URL per il webhook in arrivo. L'URL sarà simile al seguente:

    http://hooks.slack.com/services/...
    
  4. Archivia l'URL webhook in arrivo in Secret Manager:

    1. Apri la pagina Secret Manager in Google Cloud Console:

      Apri la pagina di Secret Manager

    2. Fai clic su Crea secret.

    3. Inserisci un nome per il secret.

    4. In Valore segreto, aggiungi l'URL webhook in arrivo per la tua app Slack.

    5. Per salvare il secret, fai clic su Crea secret.

  5. Anche se il tuo account di servizio Cloud Run può avere il ruolo Editor per il progetto, il ruolo Editor non è sufficiente per accedere al secret in Secret Manager. Dovrai fornire al tuo account di servizio Cloud Run l'accesso al tuo secret:

    1. Vai alla pagina IAM in Google Cloud Console:

      Apri la pagina IAM

    2. Individua l'account di servizio predefinito di Compute Engine associato al progetto:

      Il tuo account di servizio predefinito di Compute Engine sarà simile al seguente:

      project-number-compute@developer.gserviceaccount.com
      

      Prendi nota del tuo account di servizio predefinito di Compute Engine.

    3. Apri la pagina Secret Manager in Google Cloud Console:

      Apri la pagina di Secret Manager

    4. Fai clic sul nome del secret che contiene il secret per l'app Slack.

    5. Nella scheda Autorizzazioni, fai clic su Aggiungi membro.

    6. Aggiungi l'account di servizio predefinito di Compute Engine associato al progetto.

    7. Seleziona il ruolo Accesso segreto Secret Manager come ruolo.

    8. Fai clic su Salva.

  6. Concedi al tuo account di servizio Cloud Run l'autorizzazione di lettura dai bucket Cloud Storage:

    1. Vai alla pagina IAM in Google Cloud Console:

      Apri la pagina IAM

    2. Individua l'account di servizio predefinito di Compute Engine associato al progetto:

      Il tuo account di servizio predefinito di Compute Engine sarà simile al seguente:

      project-number-compute@developer.gserviceaccount.com
      
    3. Fai clic sull'icona a forma di matita nella riga contenente il tuo account di servizio predefinito di Compute Engine. Viene visualizzata la scheda Modifica autorizzazioni.

    4. Fai clic su Aggiungi un altro ruolo.

    5. Aggiungi il seguente ruolo:

      • Visualizzatore oggetti Storage
    6. Fai clic su Salva.

  7. Scrivi un file di configurazione del abilitatore per configurare il tuo strumento di notifica Slack e filtrare i dati per gli eventi di build:

    Nel seguente file di configurazione del rilevatore di esempio, il campo filter utilizza il Common Expression Language con la variabile disponibile build per filtrare gli eventi di build con uno stato SUCCESS:

    apiVersion: cloud-build-notifiers/v1
    kind: SlackNotifier
    metadata:
      name: example-slack-notifier
    spec:
      notification:
        filter: build.status == Build.Status.SUCCESS
        delivery:
          webhookUrl:
            secretRef: webhook-url
      secrets:
      - name: webhook-url
        value: projects/project-id/secrets/secret-name/versions/latest
    

    Dove:

    • webhook-url è la variabile di configurazione utilizzata in questo esempio per fare riferimento al percorso dell'URL webhook Slack archiviato in Secret Manager. Il nome della variabile specificato qui deve corrispondere al campo name in secrets.
    • project-id è l'ID del tuo progetto Cloud.
    • secret-name è il nome del tuo secret che contiene l'URL webhook di Slack.

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

    Per ulteriori campi in base ai quali è possibile applicare un filtro, consulta la risorsa Build. Per altri esempi di filtro, consulta la sezione Utilizzare la CEL per filtrare gli eventi di build.

  8. Carica il file di configurazione del visualizzatore in un bucket Cloud Storage:

    1. Se non hai un bucket Cloud Storage, esegui il comando seguente per creare un bucket, dove bucket-name è il nome che vuoi assegnare al tuo bucket, soggetto ai requisiti di denominazione.

      gsutil mb gs://bucket-name/
      
    2. Carica il file di configurazione del notificatore nel bucket:

      gsutil cp config-file-name gs://bucket-name/config-file-name
      

      Dove:

      • bucket-name è il nome del tuo bucket.
      • config-file-name è il nome del file di configurazione.
  9. Esegui il deployment del tuo notificatore in Cloud Run:

     gcloud run deploy service-name \
       --image=us-east1-docker.pkg.dev/gcb-release/cloud-build-notifiers/slack:latest \
       --no-allow-unauthenticated \
       --update-env-vars=CONFIG_PATH=config-path,PROJECT_ID=project-id
    

    Dove:

    • service-name è il nome del servizio Cloud Run a cui esegui il deployment dell'immagine.
    • config-path è il percorso del file di configurazione del visualizzatore per il tuo strumento di notifica Slack, gs://bucket-name/config-file-name.
    • project-id è l'ID del tuo progetto Cloud.

    Il comando gcloud run deploy estrae la versione più recente dell'immagine ospitata da Artifact Registry di Cloud Build. Cloud Build supporta immagini notarili per nove mesi. Dopo nove mesi, Cloud Build elimina la versione immagine. Se vuoi utilizzare una versione precedente dell'immagine, devi specificare la versione semantica completa del tag immagine nell'attributo image del comando gcloud run deploy. Le versioni precedenti delle immagini e i tag sono disponibili in Artifact Registry.

  10. Concedi le autorizzazioni Pub/Sub per creare token di autenticazione nel tuo progetto:

     gcloud projects add-iam-policy-binding project-id \
       --member=serviceAccount:service-project-number@gcp-sa-pubsub.iam.gserviceaccount.com \
       --role=roles/iam.serviceAccountTokenCreator
    

    Dove:

    • project-id è l'ID del tuo progetto Cloud.
    • project-number è il tuo numero di progetto Cloud.
  11. Crea un account di servizio per rappresentare la tua identità di abbonamento Pub/Sub:

    gcloud iam service-accounts create cloud-run-pubsub-invoker \
      --display-name "Cloud Run Pub/Sub Invoker"
    

    Puoi utilizzare cloud-run-pubsub-invoker o utilizzare un nome univoco nel tuo progetto Google Cloud.

  12. Concedi all'account di servizio cloud-run-pubsub-invoker l'autorizzazione Invoker di Cloud Run:

    gcloud run services add-iam-policy-binding service-name \
       --member=serviceAccount:cloud-run-pubsub-invoker@project-id.iam.gserviceaccount.com \
       --role=roles/run.invoker
    

    Dove:

    • service-name è il nome del servizio Cloud Run a cui esegui il deployment dell'immagine.
    • project-id è l'ID del tuo progetto Cloud.
  13. Crea l'argomento cloud-builds per ricevere i messaggi di aggiornamento sulla build per la tua notifica:

    gcloud pubsub topics create cloud-builds
    
  14. Crea un sottoscrittore push Pub/Sub per il tuo strumento di notifica:

     gcloud pubsub subscriptions create subscriber-id \
       --topic=cloud-builds \
       --push-endpoint=service-url \
       --push-auth-service-account=cloud-run-pubsub-invoker@project-id.iam.gserviceaccount.com
    

    Dove:

    • subscriber-id è il nome a cui vuoi assegnare il tuo abbonamento.
    • service-url è l'URL generato da Cloud Run per il tuo nuovo servizio.
    • project-id è l'ID del tuo progetto Cloud.

Le notifiche per il tuo progetto Cloud Build sono ora configurate. La prossima volta che richiami una build, riceverai una notifica in Slack se la build corrisponde al filtro configurato.

Utilizzo di CEL per filtrare gli eventi di build

Cloud Build utilizza CEL con la variabile build sui 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 stringa filter per filtrare gli eventi di build nel file di configurazione di compilazione utilizzando qualsiasi campo elencato nella risorsa Build. Per trovare la sintassi esatta associata al tuo campo, consulta il file cloudbuild.proto.

Filtrare per ID attivatore

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

filter: build.build_trigger_id == trigger-id

Filtrare per stato

Per filtrare in base allo stato, specifica nel campo filter lo stato della build in base a cui vuoi applicare l'applicazione build.status.

L'esempio seguente mostra come filtrare gli eventi di build con uno 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 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 dello stato in base ai quali puoi applicare il filtro, consulta la sezione Stato sotto il riferimento alla risorsa Build.

Filtrare 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 riportato di seguito, i filtri del campo filter creano eventi con esattamente due tag specificati con un tag specificato come v1:

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

Filtrare tramite immagini

Per filtrare in base alle immagini, specifica il valore dell'immagine nel campo filter utilizzando build.images, dove image-name rappresenta il nome completo dell'immagine, come elencato in Container Registry, come gcr.io/example/image-one:

filter: image-name in build.images

Nell'esempio seguente, il filtro filter mostra gli eventi di build in cui gcr.io/example/image-one o gcr.io/example/image-two sono specificati come nomi di immagini:

filter: "gcr.io/example/image-one" in build.images || "gcr.io/example/image-two" in build.images

Applicazione di filtri in base all'ora

Puoi filtrare gli eventi di build in base a un'ora di creazione, un'ora di inizio o una fine della build specificando una delle seguenti opzioni nel tuo 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 della richiesta per creare la build alle 06:00 del 20 luglio 2020:

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

Puoi anche filtrare gli eventi di compilazione in base a confronti in base all'ora. Nell'esempio seguente, il campo filter utilizza timestamp per filtrare gli eventi di build con un'ora di inizio tra le 06:00 del 20 luglio 2020 e delle ore 06:00 del 30 luglio 2020.

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

Per ulteriori informazioni su come i fusi orari vengono espressi in CEL, consulta la definizione della lingua dei 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 una build eseguita per almeno cinque minuti:

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

Filtrare in base alla sostituzione

Puoi filtrare per 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 controlla se substitution-variable corrisponde al valore substitution-value specificato:

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 predefiniti. Nel seguente esempio, il campo filter elenca le build con il nome della filiale master e quelle che hanno il nome del repository github.com/user/my-example-repo. Le variabili di sostituzione predefinite BRANCH_NAME e REPO_NAME vengono trasmesse 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 espressioni regolari, puoi utilizzare la funzione matches integrata. Nell'esempio riportato di seguito, il campo filter filtra in base alle build con uno stato FAILURE o TIMEOUT, che hanno anche una variabile di sostituzione 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 di sostituzioni predefinite.

Passaggi successivi