Cloud Build kann Ihnen Benachrichtigungen an ausgewählte Kanäle wie Slack oder Ihren SMTP-Server senden, um Sie über Build-Updates zu informieren. Auf dieser Seite wird erläutert, wie Sie Benachrichtigungen mit dem SMTP-Notifier konfigurieren.
Hinweis
Aktivieren Sie die Cloud Build API, die Compute Engine API, die Cloud Run API, die Pub/Sub API und die Secret Manager API.
Rollen, die zum Aktivieren von APIs erforderlich sind
Zum Aktivieren von APIs benötigen Sie die Berechtigung
serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Rolle „Inhaber“ (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen.
- Installieren Sie die Google Cloud CLI.
E-Mail-Benachrichtigungen konfigurieren
Zum Senden von E-Mail-Benachrichtigungen benötigen Sie einen aktiven SMTP-Server und Zugriff auf ein Konto auf diesem Server, einschließlich Nutzername und Passwort, die zum Senden von Benachrichtigungen verwendet werden. Sie können einen beliebigen vorhandenen SMTP-Server verwenden, benötigen aber Zugriff auf den Servernamen und den Port. Der Servername für Gmail ist beispielsweise smtp.gmail.com und der Port ist 587. Achten Sie darauf, dass die Lieferkontingente Ihres SMTP-Servers die E-Mail-Menge verarbeiten können, die Sie voraussichtlich generieren werden.
Im folgenden Abschnitt wird erläutert, wie Sie E-Mail-Benachrichtigungen manuell mit dem SMTP-Notifier konfigurieren können. Wenn Sie stattdessen die Konfiguration automatisieren möchten, finden Sie weitere Informationen unter Konfiguration für Benachrichtigungen automatisieren.
So konfigurieren Sie E-Mail-Benachrichtigungen:
Speichern Sie das Passwort für das E-Mail-Konto des Absenders in Secret Manager. Bei Gmail müssen Sie das App-Passwort anstelle des Passworts für die Kontoanmeldung verwenden.
Öffnen Sie die Seite „Secret Manager“ in der Google Cloud Console:
Klicken Sie auf Secret erstellen.
Geben Sie einen Namen für das Secret ein.
Fügen Sie unter Secret-Wert das E-Mail-Konto-Passwort des Absenders hinzu.
Klicken Sie zum Speichern Ihres Secrets auf Secret erstellen.
Ihr Cloud Run-Dienstkonto hat möglicherweise die Rolle Bearbeiter für Ihr Projekt. Die Rolle Bearbeiter reicht jedoch nicht für den Zugriff auf Ihr Secret in Secret Manager aus. So gewähren Sie Ihrem Cloud Run-Dienstkonto Zugriff auf Ihr Secret:
Rufen Sie in der Google Cloud Console die Seite „IAM“ auf:
Suchen Sie das Compute Engine-Standarddienstkonto , das mit Ihrem Projekt verknüpft ist:
Ihr Compute Engine-Standarddienstkonto sieht in etwa so aus:
project-number-compute@developer.gserviceaccount.comNotieren Sie sich Ihr Compute Engine-Standarddienstkonto.
Öffnen Sie die Seite „Secret Manager“ in der Google Cloud Console:
Klicken Sie auf den Secret-Namen, der das Secret für das E-Mail-Konto-Passwort Ihres Absenders enthält.
Klicken Sie im Tab Berechtigungen auf Mitglied hinzufügen.
Fügen Sie das Compute Engine-Standarddienstkonto , das mit Ihrem Projekt verknüpft ist, als Mitglied hinzu.
Wählen Sie die Berechtigung Zugriffsfunktion für Secret Manager-Secret als Rolle aus.
Klicken Sie auf Speichern.
Gewähren Sie Ihrem Cloud Run-Dienstkonto die Berechtigung zum Lesen aus Cloud Storage-Buckets:
Rufen Sie in der Google Cloud Console die Seite „IAM“ auf:
Suchen Sie das Compute Engine-Standarddienstkonto , das mit Ihrem Projekt verknüpft ist:
Ihr Compute Engine-Standarddienstkonto sieht in etwa so aus:
project-number-compute@developer.gserviceaccount.comKlicken Sie in der Zeile mit Ihrem Compute Engine-Standarddienstkonto auf das Stiftsymbol. Der Tab Bearbeitungszugriff wird angezeigt.
Klicken Sie auf Weitere Rolle hinzufügen.
Fügen Sie die folgende Rolle hinzu:
- Storage-Objekt-Betrachter
Klicken Sie auf Speichern.
Schreiben Sie eine Notifier-Konfigurationsdatei, um Ihren SMTP-Notifier zu konfigurieren und nach Build-Ereignissen zu filtern:
In der folgenden Konfigurationsdatei für Notifier wird im Feld
filterdie Option Common Expression Language mit der verfügbaren Variablebuildverwendet, um Build-Ereignisse mit dem StatusSUCCESSzu filtern:apiVersion: cloud-build-notifiers/v1 kind: SMTPNotifier metadata: name: example-smtp-notifier spec: notification: filter: build.status == Build.Status.SUCCESS params: buildStatus: $(build.status) delivery: server: SERVER_HOST_NAME port: "PORT" sender: SENDER_EMAIL from: FROM_EMAIL recipients: - RECIPIENT_EMAIL # optional: more emails here password: secretRef: smtp-password template: type: golang uri: gs://BUCKET_NAME/smtp.html secrets: - name: smtp-password value: projects/PROJECT_ID/secrets/SECRET_NAME/versions/latestHierbei gilt:
buildStatusist ein benutzerdefinierter Parameter. Dieser Parameter nimmt den Wert von $(build.status) an, dem Status des Builds.BUCKET_NAMEist der Name des Buckets.SERVER_HOST_NAMEist die Adresse Ihres SMTP-Servers.PORTist der Port, der SMTP-Anfragen verarbeitet. Dieser Wert sollte als String angegeben werden.SENDER_EMAIList die E-Mail-Adresse des Absenderkontos, die dem angegebenen SERVER_HOST_NAME angezeigt wird.FROM_EMAIList die E-Mail-Adresse, die für Empfänger angezeigt wird.RECIPIENT_EMAIList eine Liste mit einer oder mehreren E-Mail-Adressen, um Nachrichten vom Absender zu empfangen.smtp-passwordist die Konfigurationsvariable, die in diesem Beispiel verwendet wird, um auf das im Secret Manager gespeicherte E-Mail-Konto-Passwort des Absenders zu verweisen. Der hier angegebene Variablenname sollte dem Feldnameuntersecretsentsprechen.PROJECT_IDist die ID des Google Cloud Projekts.SECRET_NAMEist der Name Ihres Secrets, das das Passwort für das E-Mail-Konto des Absenders enthält.Das Feld
uriverweist auf die Dateismtp.html. Diese Datei verweist auf eine HTML-Vorlage, die in Cloud Storage gehostet wird und Ihre Benachrichtigungs-E-Mail darstellt.
Das Beispiel finden Sie in der Konfigurationsdatei für Notifier für die SMTP Notifier.
Weitere Felder, nach denen Sie filtern können, finden Sie in der Ressource Build. Weitere Filterbeispiele finden Sie unter CEL zum Filtern von Build-Ereignissen verwenden.
Laden Sie die Notifier-Konfigurationsdatei in einen Cloud Storage-Bucket hoch:
Wenn Sie keinen Cloud Storage-Bucket haben, führen Sie den folgenden Befehl aus, um einen Bucket zu erstellen. Dabei ist
BUCKET_NAMEder Name, den Sie Ihrem Bucket gemäß den Vorgaben für die Benennung geben möchten.gcloud storage buckets create gs://BUCKET_NAME/Laden Sie die Konfigurationsdatei für den Notifier in Ihren Bucket hoch:
gcloud storage cp CONFIG_FILE_NAME gs://BUCKET_NAME/CONFIG_FILE_NAMEHierbei gilt:
BUCKET_NAMEist der Name des Buckets.CONFIG_FILE_NAMEist der Name Ihrer Konfigurationsdatei.
Stellen Sie den Notifier in Cloud Run bereit.
gcloud run deploy SERVICE_NAME \ --image=us-east1-docker.pkg.dev/gcb-release/cloud-build-notifiers/smtp:latest \ --no-allow-unauthenticated \ --update-env-vars=CONFIG_PATH=CONFIG_PATH,PROJECT_ID=PROJECT_IDHierbei gilt:
SERVICE_NAMEist der Name des Cloud Run-Dienstes, in dem Sie das Image bereitstellen.CONFIG_PATHist der Pfad zur Notifier-Konfigurationsdatei für Ihre SMTP Benachrichtigungengs://BUCKET_NAME/CONFIG_FILE_NAME.PROJECT_IDist die ID des Google Cloud Projekts.
Der
gcloud run deployBefehl ruft die neueste Version des gehosteten Images aus der Cloud Build-Artifact Registry ab. Cloud Build unterstützt Notifier-Images neun Monate lang. Nach neun Monaten löscht Cloud Build die Image-Version. Wenn Sie eine frühere Image-Version verwenden möchten, müssen Sie die vollständige semantische Version des Image-Tags im AttributimageIhresgcloud run deploy-Befehls angeben. Ältere Image-Versionen und Tags finden Sie in Artifact Registry.Erstellen Sie ein Dienstkonto, das die Pub/Sub-Abonnementidentität darstellen soll:
gcloud iam service-accounts create SUB_IDENTITY_SERVICE_ACCOUNT \ --display-name "SUB_IDENTITY_SERVICE_ACCOUNT_DISPLAY_NAME"Hierbei gilt:
SUB_IDENTITY_SERVICE_ACCOUNTist ein Name für das Dienstkonto.SUB_IDENTITY_SERVICE_ACCOUNT_DISPLAY_NAMEist ein Anzeigename für das Dienstkonto.
Gewähren Sie dem Dienstkonto für die Pub/Sub-Abonnementidentität die Berechtigungen, die zum Erstellen von Authentifizierungstokens in Ihrem Google Cloud Projekt erforderlich sind.
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.serviceAccountTokenCreatorHierbei gilt:
PROJECT_IDist die ID des Google Cloud Projekts.PROJECT_NUMBERist Ihre Google Cloud Projektnummer.
Weisen Sie dem Dienst0/} die Cloud Run
InvokerRolle zu:SUB_IDENTITY_SERVICE_ACCOUNTgcloud run services add-iam-policy-binding SERVICE_NAME \ --member=serviceAccount:SUB_IDENTITY_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/run.invokerHierbei gilt:
SERVICE_NAMEist der Name des Cloud Run-Dienstes, in dem Sie das Image bereitstellen.PROJECT_IDist die ID des Google Cloud Projekts.
Erstellen Sie das Thema
cloud-builds, um Build-Update-Nachrichten für Ihren Notifier zu erhalten:gcloud pubsub topics create cloud-buildsSie können auch einen benutzerdefinierten Themennamen in Ihrer Build-Konfigurationsdatei definieren , damit Nachrichten stattdessen an das benutzerdefinierte Thema gesendet werden. In diesem Fall erstellen Sie ein Thema mit demselben benutzerdefinierten Themennamen:
gcloud pubsub topics create topic-nameWeitere Informationen finden Sie unter Pub/Sub-Themen für Build-Benachrichtigungen.
Erstellen Sie einen Pub/Sub-Push-Abonnenten für Ihren Notifier:
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
Hierbei gilt:
+ SUBSCRIBER_ID ist der Name, den Sie Ihrem Abo geben möchten.
+ SERVICE_URL ist die von Cloud Run generierte URL für Ihren neuen Dienst.
+ PROJECT_ID ist die ID des Google Cloud Projekts.
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.
Benachrichtigungen sind nun für Ihr Cloud Build-Projekt eingerichtet. Wenn Sie das nächste Mal einen Build aufrufen, erhält der angegebene recipients eine E-Mail mit einer Benachrichtigung, wenn der Build dem von Ihnen konfigurierten Filter entspricht.
Build-Ereignisse mit CEL filtern
Cloud Build verwendet CEL mit der Variablen build für Felder in der Ressource Build, um auf Felder zuzugreifen, die mit Ihrem Build-Ereignis verknüpft sind, z. B. Ihre Trigger-ID, Image-Liste oder Ersatzwerte. Sie können den filter
String verwenden, um Build-Ereignisse in Ihrer Build-Konfigurationsdatei mit
einem Feld zu filtern, das in der Ressource Build
aufgeführt ist. Die genaue Syntax, die dem Feld zugeordnet ist, finden Sie in der
cloudbuild.proto
Datei.
Nach Trigger-ID filtern
Wenn Sie nach Trigger-ID filtern möchten, geben Sie den Wert Ihrer Trigger-ID im Feld filter mit build.build_trigger_id an. Dabei ist trigger-id Ihre Trigger-ID als String:
filter: build.build_trigger_id == trigger-id
Nach Status filtern
Geben Sie im Feld filter mithilfe von build.status den Build-Status an, nach dem der Filter gefiltert werden soll.
Das folgende Beispiel zeigt, wie Sie Build-Ereignisse mit dem Status SUCCESS mithilfe des Felds filter filtern:
filter: build.status == Build.Status.SUCCESS
Sie können auch Builds mit unterschiedlichen Status filtern. Das folgende Beispiel zeigt, wie Build-Ereignisse mit dem Status SUCCESS, FAILURE oder TIMEOUT mit dem Feld filter gefiltert werden:
filter: build.status in [Build.Status.SUCCESS, Build.Status.FAILURE, Build.Status.TIMEOUT]
Weitere Statuswerte, nach denen Sie filtern können, finden Sie in der Referenz zu Build-Ressourcen unter Status.
Nach Tag filtern
Geben Sie zum Filtern nach Tag den Wert Ihres Tags im Feld filter mit build.tags ein, wobei tag-name der Name des Tags ist:
filter: tag-name in build.tags
Mit size können Sie nach der Anzahl der in Ihrem Build-Ereignis angegebenen Tags filtern. Im folgenden Beispiel filtert das Feld filter Build-Ereignisse, bei denen genau zwei Tags angegeben sind, wobei ein Tag als v1 angegeben ist:
filter: size(build.tags) == 2 && "v1" in build.tags
Nach Images filtern
Wenn Sie nach Images filtern möchten, geben Sie den Wert Ihres Images im Feld filter mit build.images an, wobei image-name der vollständige Name des Images ist, wie in Artifact Registry aufgeführt, z. B. us-east1-docker.pkg.dev/my-project/docker-repo/image-one:
filter: image-name in build.images
Im folgenden Beispiel filtert filter nach Build-Ereignissen, in denen entweder us-east1-docker.pkg.dev/my-project/docker-repo/image-one oder us-east1-docker.pkg.dev/my-project/docker-repo/image-two als Bildnamen angegeben ist:
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
Nach Zeitraum filtern
Sie können Build-Ereignisse nach der Erstellungszeit, dem Beginn oder dem Ende eines Builds filtern. Geben Sie dazu in Ihrem Feld filter eine der folgenden Optionen an: build.create_time, build.start_time oder build.finish_time zurück.
Im folgenden Beispiel verwendet das Feld filter timestamp, um Build-Ereignisse mit einer Anfragezeit zu filtern, um den Build am 20. Juli 2020 um 6:00 Uhr zu erstellen:
filter: build.create_time == timestamp("2020-07-20:T06:00:00Z")
Sie können Build-Ereignisse auch nach Zeitvergleichen filtern. Im folgenden Beispiel verwendet das Feld filter timestamp, um Build-Ereignisse mit einer Startzeit zwischen dem 20. Juli 2020, 6:00 Uhr und dem 30. Juli 2020 um 6:00 Uhr zu filtern. , um die Option zu aktivieren.
filter: timestamp("2020-07-20:T06:00:00Z") >= build.start_time && build.start_time <= timestamp("2020-07-30:T06:00:00Z")
Weitere Informationen dazu, wie Zeitzonen in CEL ausgedrückt werden, finden Sie in der Sprachdefinition für Zeitzonen.
Zum Filtern nach der Dauer eines Builds können Sie duration verwenden, um Zeitstempel zu vergleichen.
Im folgenden Beispiel verwendet das Feld filter duration, um Build-Ereignisse mit Builds zu filtern, die mindestens fünf Minuten lang ausgeführt werden:
filter: build.finish_time - build.start_time >= duration("5m")
Nach Substitution filtern
Sie können nach Substitution filtern, wenn Sie die Substitutionsvariable im Feld filter mit build.substitutions angeben. Im folgenden Beispiel listet das Feld filter Builds auf, die die Substitutionsvariable substitution-variable enthalten, und prüft, ob substitution-variable mit dem angegebenen substitution-value übereinstimmt:
filter: build.substitutions[substitution-variable] == substitution-value
Hierbei gilt:
substitution-variableist der Name der Substitutionsvariablen.substitution-valueist der Name Ihres Substitutionswerts.
Sie können auch nach Standardwerten für Substitutionsvariablen filtern. Im folgenden Beispiel werden im Feld filter Builds mit dem Zweignamen master und Builds mit dem Repository-Namen github.com/user/my-example-repo aufgelistet. Die Standardsubstitutionsvariablen BRANCH_NAME und REPO_NAME werden als Schlüssel an build.substitutions übergeben:
filter: build.substitutions["BRANCH_NAME"] == "master" && build.substitutions["REPO_NAME"] == "github.com/user/my-example-repo"
Wenn Sie mithilfe von regulären Ausdrücken nach Strings filtern möchten, können Sie die integrierte Funktion matches verwenden. Im folgenden Beispiel filtert das Feld filter nach Builds mit dem Status FAILURE oder TIMEOUT und einer Build-Substitutionsvariablen TAG_NAME mit einem Wert, der dem regulären Ausdruck v{DIGIT}.{DIGIT}.{3 DIGITS}) entspricht.
filter: build.status in [Build.Status.FAILURE, Build.Status.TIMEOUT] && build.substitutions["TAG_NAME"].matches("^v\\d{1}\\.\\d{1}\\.\\d{3}$")
Eine Liste der Standardsubstitutionswerte finden Sie unter Standardsubstitutionen verwenden.
Nächste Schritte
- Informationen zu Cloud Build-Benachrichtigungen.
- Build-Benachrichtigungen abonnieren
- Build-Konfigurationsdatei für Cloud Build schreiben