Diese Seite wurde von der Cloud Translation API übersetzt.

GitHub-Problembenachrichtigungen konfigurieren

Cloud Build kann Sie über Build-Updates benachrichtigen, indem Sie Du erhältst Benachrichtigungen an die gewünschten Kanäle. Auf dieser Seite wird erläutert, wie Sie Benachrichtigungen mit dem GitHub-Issues-Notifier konfigurieren.

Hinweise

Enable the Cloud Build, Compute Engine, Cloud Run, Pub/Sub, and Secret Manager APIs.
Enable the APIs

Installieren Sie die Google Cloud CLI.

GitHub-Problembenachrichtigungen konfigurieren

Im folgenden Abschnitt wird erläutert, wie Sie Benachrichtigungen zu GitHub-Problemen manuell konfigurieren können mit dem GitHub-Problembenachrichtigung. Wenn Sie stattdessen die Konfiguration automatisieren möchten, finden Sie weitere Informationen unter Konfiguration für Benachrichtigungen automatisieren.

So konfigurieren Sie GitHub-Probleme:

Erstellen Sie ein persönliches GitHub-Zugriffstoken:
1. Rufen Sie die GitHub-Einstellungen auf, um ein neues Token zu erstellen.
2. Wählen Sie den Bereich repo aus.
  
  Hinweis: Dadurch erhalten Sie vollen Zugriff auf Repositories, einschließlich privater Repositories.
3. Klicken Sie auf Token generieren.
Speichern Sie Ihr GitHub-Token in Secret Manager:
1. Öffnen Sie in der Google Cloud Console die Seite „Secret Manager“:
  
  Zur Seite "Secret Manager"
2. Klicken Sie auf Secret erstellen.
3. Geben Sie einen Namen für das Secret ein.
4. Fügen Sie unter Secret-Wert Ihr GitHub-Token hinzu.
5. 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. Sie müssen Ihrem Cloud Run-Dienstkonto Zugriff auf Ihr Secret gewähren:
1. Rufen Sie in der Google Cloud Console die IAM-Seite auf:
  
  Seite "IAM" öffnen
2. 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.com
```
  Notieren Sie sich das Compute Engine-Standarddienstkonto.
  
  Hinweis: Standardmäßig führt Cloud Run Ihre Notifier-Images mit dem Compute Engine-Standarddienstkonto aus und ruft damit das Secret ab. Weitere Informationen zu Runtime-Dienstkonten finden Sie unter Runtime-Dienstkonto.
3. Öffnen Sie in der Google Cloud Console die Seite „Secret Manager“:
  
  Zur Seite "Secret Manager"
4. Klicken Sie auf den Secret-Namen, der Ihr GitHub-Token enthält.
5. Klicken Sie im Tab Berechtigungen auf Mitglied hinzufügen.
6. Fügen Sie das mit Ihrem Projekt verknüpfte Compute Engine-Standarddienstkonto als Mitglied hinzu.
7. Wählen Sie die Berechtigung Zugriffsfunktion für Secret Manager-Secret als Rolle aus.
8. Klicken Sie auf Speichern.
Gewähren Sie Ihrem Cloud Run-Dienstkonto die Berechtigung zum Lesen von Cloud Storage-Buckets:
1. Rufen Sie in der Google Cloud Console die IAM-Seite auf:
  
  Seite "IAM" öffnen
2. 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.com
```
3. Klicken Sie auf das Stiftsymbol in der Zeile, die das Compute Engine-Standarddienstkonto enthält. Der Tab Bearbeitungszugriff wird angezeigt.
4. Klicken Sie auf Weitere Rolle hinzufügen.
5. Fügen Sie die folgende Rolle hinzu:
  - Storage-Objekt-Betrachter
  Hinweis: Wenn Sie Berechtigungen auf Bucket-Ebene statt auf Projektebene gewähren möchten, fügen Sie die Rolle Inhaber alter Storage-Objekte zum Bucket hinzu, wenn Sie diesen erstellen. Weitere Informationen finden Sie unter Rollen auf Projektebene im Vergleich zu Rollen auf Bucket-Ebene.
6. Klicken Sie auf Speichern.
Schreiben Sie eine Vorlagenkonfigurationsdatei, in der das Format für die erstellten GitHub-Probleme beschrieben wird:

In der folgenden Beispielkonfigurationsdatei für eine Vorlage verwenden die Felder title und body die Substitutionsvariablen aus dem Build:
```
{
    "title": "Build {{.Build.BuildTriggerId}}: {{.Build.Status}}",
    "body": "[{{.Build.ProjectId}}] {{.Build.BuildTriggerId}} status: **{{.Build.Status}}**\n\n[View Logs]({{.Build.LogUrl}})"
}
```
Das Beispiel finden Sie in der Konfigurationsdatei der Vorlage für den GitHub-Issues-Notifier.

Zusätzliche Felder können über die verfügbaren „body“-Parameter vom GitHub API-Endpunkt zum Erstellen eines Problems festgelegt werden.
Schreiben Sie eine Konfigurationsdatei, um Ihren GitHub-Issues-Notifier zu konfigurieren und nach Build-Ereignissen zu filtern:

In der folgenden Konfigurationsdatei für Notifier wird im Feld filter die Option Common Expression Language mit der verfügbaren Variable build verwendet, um Build-Ereignisse mit dem Status SUCCESS zu filtern:
```
apiVersion: cloud-build-notifiers/v1
kind: GitHubIssuesNotifier
metadata:
  name: example-githubissues-notifier
spec:
  notification:
    filter: build.status == Build.Status.FAILURE
    template: 
      type: golang
      uri: gs://bucket_name/template-file-name
    delivery:
      githubToken:
        secretRef: github-token
      githubRepo: myuser/myrepo
  secrets:
  - name: github-token
    value: projects/project-id/secrets/secret-name/versions/latest
```
Wobei:
- githubToken ist die Konfigurationsvariable, die in diesem Beispiel verwendet wird, um auf das in Secret Manager gespeicherte GitHub-Token verweisen. Der hier angegebene Variablenname sollte dem Feld name unter secrets entsprechen.
- bucket-name ist der Name des Buckets.
- template-file-name ist der Name der Vorlagendatei.
- myuser/myrepo ist der Name des Repositorys, für das Probleme erstellt werden.
- project-id ist die ID des Google Cloud-Projekts.
- secret-name ist der Name Ihres Secrets, das Ihr GitHub-Token enthält.
Das Beispiel finden Sie in der Konfigurationsdatei des Notifiers für die GitHub-Probleme. 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 und die Vorlagendatei in einen Cloud Storage-Bucket hoch:
1. Wenn Sie keinen Cloud Storage-Bucket haben, führen Sie den folgenden Befehl aus, um einen Bucket zu erstellen. Dabei ist bucket-name der Name, den Sie Ihrem Bucket gemäß den Vorgaben für die Benennung geben sollten.
```
gcloud storage buckets create gs://bucket-name/
```
2. Laden Sie die Konfigurationsdatei für den Notifier und die Vorlagendatei in Ihren Bucket hoch:
```
gcloud storage cp config-file-name gs://bucket-name/config-file-name

gcloud storage cp config-file-name gs://bucket-name/config-file-name
```
  Wobei:
  - bucket-name ist der Name des Buckets.
  - config-file-name ist der Name Ihrer Konfigurationsdatei.
  - template-file-name ist der Name der Vorlagendatei.
Stellen Sie den Notifier in Cloud Run bereit.
```
 gcloud run deploy service-name \
   --image=us-east1-docker.pkg.dev/gcb-release/cloud-build-notifiers/githubissues:latest \
   --no-allow-unauthenticated \
   --update-env-vars=CONFIG_PATH=config-path,PROJECT_ID=project-id
```
Hierbei gilt:
- service-name ist der Name des Cloud Run-Dienstes, in dem Sie das Image bereitstellen.
  
  Hinweis :service-name verweist auf den neuen Notifier-Dienst, den Sie erstellen.
- config-path ist der Pfad zur Notifier-Konfigurationsdatei für Ihren GitHub-Issues-Notifier gs://bucket-name/config-file-name.
- project-id ist die ID des Google Cloud-Projekts.
Der Befehl gcloud run deploy 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 Attribut image Ihres gcloud run deploy-Befehls angeben. Ältere Image-Versionen und Tags finden Sie in Artifact Registry.

Hinweis: Bei der Ausführung dieses Befehls werden Sie möglicherweise aufgefordert, zusätzliche Argumente wie --region oder --platform anzugeben. Weitere Informationen zu den Parametern, die Sie an den Befehl gcloud run deploy übergeben können, finden Sie unter In Cloud Run bereitstellen. Wenn Sie den Notifier mit diesem Befehl nicht bereitstellen können, lesen Sie die Anleitung zur Fehlerbehebung in Cloud Run. Hier finden Sie Lösungen zum Beheben von Bereitstellungsfehlern.
Gewähren Sie Pub/Sub-Berechtigungen zum Erstellen von Authentifizierungstokens in Ihrem Projekt:
```
 gcloud projects add-iam-policy-binding project-id \
   --member=serviceAccount:service-project-number@gcp-sa-pubsub.iam.gserviceaccount.com \
   --role=roles/iam.serviceAccountTokenCreator
```
Wobei:
- project-id ist die ID des Google Cloud-Projekts.
- project-number ist die Nummer Ihres Google Cloud-Projekts.
Hinweis: Wenn das Pub/Sub-Dienstkonto in Informationen zu Ihrem Projekt finden Sie unter Abos erstellen und verwenden.
Erstellen Sie ein Dienstkonto, das die Pub/Sub-Abonnementidentität darstellen soll:
```
gcloud iam service-accounts create cloud-run-pubsub-invoker \
  --display-name "Cloud Run Pub/Sub Invoker"
```
Sie können cloud-run-pubsub-invoker oder einen innerhalb Ihres Google Cloud-Projekts eindeutigen Namen verwenden.
Weisen Sie dem Dienstkonto cloud-run-pubsub-invoker die Cloud Run-Berechtigung Invoker zu:
```
gcloud run services add-iam-policy-binding service-name \
   --member=serviceAccount:cloud-run-pubsub-invoker@project-id.iam.gserviceaccount.com \
   --role=roles/run.invoker
```
Hierbei gilt:
- service-name ist der Name des Cloud Run-Dienstes, in dem Sie das Image bereitstellen.
- project-id ist 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-builds
```
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=cloud-run-pubsub-invoker@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.

Benachrichtigungen sind nun für Ihr Cloud Build-Projekt eingerichtet. Die nächste wenn Sie einen Build aufrufen, wird ein Problem mit dem definierten GitHub-Repository erstellt, wenn der Build entspricht dem von Ihnen konfigurierten Filter.

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 String filter verwenden, um Build-Ereignisse in Ihrer Build-Konfigurationsdatei mit einem Feld zu filtern, das in der Ressource Build aufgeführt ist. Die genaue Syntax für Ihr Feld finden Sie auf 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

Geben Sie den Wert des Bildes im Feld filter an, um nach Bildern zu filtern mit build.images, wobei image-name der vollständige Name 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, die entweder us-east1-docker.pkg.dev/my-project/docker-repo/image-one oder us-east1-docker.pkg.dev/my-project/docker-repo/image-two angegeben als Image-Namen:

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-variable ist der Name der Substitutionsvariablen.
substitution-value ist 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.

GitHub-Problembenachrichtigungen konfigurieren

Hinweise

GitHub-Problembenachrichtigungen konfigurieren

Build-Ereignisse mit CEL filtern

Nach Trigger-ID filtern

Nach Status filtern

Nach Tag filtern

Nach Images filtern

Nach Zeitraum filtern

Nach Substitution filtern

Nächste Schritte