Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Builds als Reaktion auf Webhook-Ereignisse automatisieren

Mit Cloud Build können Sie Webhook-Trigger definieren, die eingehende Webhook-Ereignisse authentifizieren und akzeptieren. Mit diesen Ereignissen, die an eine benutzerdefinierte URL gesendet werden, können Sie externe Systeme und externe Quellcodeverwaltungssysteme wie Bitbucket.com, Bitbucket Server oder GitLab über Webhook-Ereignisse direkt mit Cloud Build verbinden.

Mit Webhook-Triggern können Sie eine Inline-Build-Konfigurationsdatei definieren, anstatt beim Erstellen des Triggers eine Quelle anzugeben. Mit der Inline-Build-Konfiguration können Sie die Git-Vorgänge steuern und den Rest des Builds definieren.

Auf dieser Seite wird beschrieben, wie Sie Webhook-Trigger erstellen können, um Builds als Reaktion auf Webhook-Ereignisse zu automatisieren.

Hinweis :Wenn Sie einen Trigger erstellen, der Builds bei Repository-Ereignissen automatisiert, empfehlen wir die Verwendung von Cloud Build-Repository-Triggern. Repository-Trigger, die Cloud Build-Repositories (2. Generation) verwenden, können programmatisch konfiguriert werden und sind in Quellanbieter integriert, einschließlich Unterstützung für GitHub und GitLab. Cloud Build-Repositories (2. Generation) verwalten auch Authentifizierungstokens und Informationen in Ihrem Namen mit Secret Manager. Mit Repository-Triggern können Sie eingehende Ereignisse filtern und den Build-Status an den Quellanbieter zurückgeben. Sie können auch so konfiguriert werden, dass sie mit einem privaten Netzwerk funktionieren. Weitere Informationen finden Sie auf der Seite Repositories – Übersicht.

Hinweis

Aktivieren Sie die Cloud Build API und die Secret Manager API.
Rollen, die zum Aktivieren von APIs erforderlich sind
Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Weitere Informationen zum Zuweisen von Rollen
APIs aktivieren

Wenn Sie die gcloud-Befehle auf dieser Seite verwenden möchten, installieren Sie die Google Cloud CLI.

Hinweis: Wenn Sie die gcloud CLI bereits installiert haben, prüfen Sie, ob Sie die neueste verfügbare Version haben. Führen Sie dazu den Befehl gcloud components update aus.
Wenn Ihr Webhook-Trigger ein Cloud Build-Repository als Quelle verwendet, sollten Sie sich mit Cloud Build-Repositories vertraut machen.

Webhook-Trigger erstellen

Console

So erstellen Sie einen Webhook-Trigger mit der Google Cloud Console:

Seite "Trigger" aufrufen

Zur Seite "Build-Trigger"
Wählen Sie das Projekt oben auf der Seite aus und klicken Sie auf Öffnen.
Klicken Sie auf Trigger erstellen.
Geben Sie die folgenden Triggereinstellungen ein:
- Name: Ein Name für Ihren Trigger
- Region: Wählen Sie die Region für Ihren Trigger aus.
  - Wenn in der mit dem Trigger verknüpften Build-Konfigurationsdatei ein privater Pool angegeben ist, verwendet Cloud Build den privaten Pool zum Ausführen des Builds. In diesem Fall muss die Region, die Sie in Ihrem Trigger angeben, mit der Region übereinstimmen, in der Sie Ihren privaten Pool erstellt haben.
  - Wenn in der mit dem Trigger verknüpften Build-Konfigurationsdatei kein privater Pool angegeben ist, verwendet Cloud Build den Standardpool, um den Build in derselben Region wie den Trigger auszuführen.
- Beschreibung Optional: Eine Beschreibung für Ihren Trigger.
- Ereignis: Wählen Sie Webhook-Ereignis aus, um den Trigger so einzurichten, dass Builds als Reaktion auf eingehende Webhook-Ereignisse starten.
- Webhook-URL: Verwenden Sie die Webhook-URL, um eingehende Webhook-Ereignisse zu authentifizieren. Sie benötigen ein Secret für die Authentifizierung eingehender Webhook-Ereignisse. Sie können ein neues Secret erstellen oder ein vorhandenes verwenden. Dieses Secret ist vom Secret für Ihren SSH-Schlüssel getrennt.
  
  So erstellen Sie ein Secret:
  1. Wählen Sie Neues Secret verwenden (von Cloud Build generiert) aus.
  2. Klicken Sie auf Secret erstellen.
    
    Das Dialogfeld Webhook-Secret erstellen wird angezeigt.
  3. Geben Sie im Feld Secret-Name einen Namen für Ihr Secret ein.
  4. Klicken Sie auf Secret erstellen, um Ihr Secret zu speichern. Es wird automatisch im Secret Manager erstellt und gespeichert.
  So verwenden Sie ein vorhandenes Secret:
  1. Wählen Sie Vorhandenes Secret verwenden oder eigenes erstellen aus.
  2. Wählen Sie im Feld Secret den Namen des Secrets aus dem Drop-down-Menü aus oder folgen Sie der Anleitung, um ein Secret nach Ressourcen-ID hinzuzufügen.
  3. Wählen Sie im Feld Secret-Version Ihre Secret-Version aus dem Drop-down-Menü aus.
    
    Wenn Sie ein vorhandenes Secret verwenden, müssen Sie dem Cloud Build-Dienstkonto service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com möglicherweise die Rolle Zugriffsperson für Secret Manager-Secret manuell zuweisen. Weitere Informationen finden Sie unter Dienstkonto die Rolle Secret Manager zuweisen.
    
    Nachdem Sie Ihr Secret erstellt oder ausgewählt haben, wird eine Webhook-URL-Vorschau angezeigt. Ihre URL enthält einen von Cloud Build und Ihrem Secret generierten API-Schlüssel. Wenn Cloud Build nicht in der Lage ist, Ihren API-Schlüssel abzurufen, können Sie Ihren API-Schlüssel manuell zur URL hinzufügen oder erfahren Sie, wie Sie einen API-Schlüssel erhalten, wenn Sie noch keinen haben.
    
    Sie können die URL verwenden, um ein Webhook-Ereignis aufzurufen. Erstellen Sie dazu eine HTTP-Anfrage mit der POST-Methode.
    
    Nach Abschluss dieser Schritte wird Ihrem Cloud Build-Dienst-Agent service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com automatisch die Rolle Zugriffsperson für Secret Manager-Secret zugewiesen. Wenn diese Rolle nicht automatisch Ihrem Dienst-Agent hinzugefügt wird, führen Sie die folgenden Schritte aus, die unter Dienstkonto die Rolle Secret Manager zuweisen beschrieben werden.
- Quelle (optional): Wenn Sie eine Inline-Build-Konfiguration angeben, müssen Sie keine Quelle angeben. Gehen Sie andernfalls so vor:
  - Repository-Generation: Wählen Sie 2. Generationaus.
  - Repository: Wählen Sie aus der Liste der verfügbaren Repositories das Repository aus, aus dem Sie erstellen möchten. Die Region Ihres Repositorys muss mit der Region Ihres Triggers übereinstimmen.
  - Zweig oder Tag: Geben Sie einen regulären Ausdruck mit dem abzugleichenden Zweig- oder Tag-Wert an. Informationen zur zulässigen Syntax für reguläre Ausdrücke finden Sie unter RE2-Syntax.
  - Kommentarsteuerung: Wenn Sie Pull-Anfrage als Ereignis ausgewählt haben, wählen Sie eine der folgenden Optionen aus, um zu steuern, ob der Trigger automatisch einen Build aufruft:
    
    Warnung :Jeder Nutzer mit Lesezugriff auf das Repository kann eine Pull-Anfrage senden. Diese kann einen Build ausführen, der Änderungen am Quellcode in der Pull-Anfrage enthält. Wenn Sie dieses Verhalten deaktivieren möchten, empfehlen wir die Verwendung manueller Genehmigungen, um Builds zu steuern, wenn Sie Pull-Anfragen an öffentliche Repositories stellen. Weitere Informationen zu Build-Berechtigungen für Trigger
    - Erforderlich, außer für Inhaber und Mitbearbeiter: Wenn eine Pull-Anfrage von einem Repository-Inhaber oder Mitbearbeiter erstellt oder aktualisiert wird, werden Builds automatisch ausgeführt. Wenn ein externer Mitwirkender die Aktion initiiert, werden Builds nur ausgeführt, nachdem ein Inhaber oder Mitbearbeiter /gcbrun zur Pull-Anfrage kommentiert hat.
    - Erforderlich: Wenn eine Pull-Anfrage von einem Mitwirkenden erstellt oder aktualisiert wird, werden Builds erst ausgeführt, nachdem ein Inhaber oder Mitbearbeiter /gcbrun zu der Pull-Anfrage kommentiert hat. Builds werden jedes Mal ausgeführt, wenn eine Änderung an einer Pull-Anfrage vorgenommen wird.
    - Nicht erforderlich: Wenn eine Pull-Anfrage von einem Mitwirkenden erstellt oder aktualisiert wird, werden Builds automatisch ausgeführt.
- Konfiguration: Wählen Sie die Build-Konfigurationsdatei aus, die sich in Ihrem Remote-Repository befindet, oder erstellen Sie eine Inline-Build-Konfigurationsdatei für den Build. Wenn Sie kein Quell-Repository angegeben haben, müssen Sie eine Inline-Build-Konfigurationsdatei als Konfigurationsoption auswählen:
  - Typ: Wählen Sie den Konfigurationstyp aus, der für Ihren Build verwendet werden soll.
    - Cloud Build-Konfigurationsdatei (YAML oder JSON): Verwenden Sie eine Build-Konfigurationsdatei für Ihre Konfiguration.
    - Dockerfile: Verwenden Sie für Ihre Konfiguration eine Dockerfile.
    - Buildpacks: Verwenden Sie Buildpacks für Ihre Konfiguration.
  - Speicherort: Geben Sie den Speicherort für Ihre Konfiguration an.
    - Repository: Wenn sich Ihre Konfigurationsdatei in Ihrem Remote-Repository befindet, geben Sie den Speicherort Ihrer Build-Konfigurationsdatei, das Verzeichnis der Dockerfile oder das Verzeichnis der Buildpacks an. Wenn Ihr Build-Konfigurationstyp eine Dockerfile oder ein Buildpack ist, müssen Sie einen Namen für das resultierende Image und optional ein Zeitlimit für den Build angeben. Wenn Sie den Image-Namen der Dockerfile oder des Buildpacks angegeben haben, sehen Sie eine Vorschau des Befehls docker build oder pack, den Ihr Build ausführen wird.
    - Buildpack-Umgebungsvariablen (Optional): Wenn Sie buildpacks als Konfigurationstyp ausgewählt haben, klicken Sie auf Pack-Umgebungsvariable hinzufügen, um Ihre Buildpack-Umgebungsvariablen und -werte anzugeben. Weitere Informationen zu Buildpack-Umgebungsvariablen finden Sie unter Umgebungsvariablen.
    - Inline: Wenn Sie die Cloud Build-Konfigurationsdatei (YAML oder JSON) als Konfigurationsoption ausgewählt haben, können Sie die Build-Konfiguration inline angeben. Klicken Sie auf Editor öffnen, um Ihre Build-Konfigurationsdatei in derGoogle Cloud console in der YAML- oder JSON-Syntax zu schreiben. Klicken Sie auf Fertig, um die Build-Konfiguration zu speichern.
      
      Hinweis: Die Unterstützung der Inline-Build-Konfiguration ist für Dockerfile oder Buildpacks nicht verfügbar.
  Im folgenden Beispiel gibt die Inline-Build-Konfigurationsdateilogs "hello world" zurück:
```
 steps:
 - name: 'ubuntu'
   args: ['echo', 'hello world']
```
- Substitutionen (optional): Wenn Sie die Build-Konfigurationsdatei als Ihre Build-Konfigurationsoption ausgewählt oder eine Inline-Build-Konfigurationsdatei erstellt haben, können Sie in diesem Feld trigger-spezifische Substitutionsvariablen definieren. Sie können Daten auch mit Nutzlastbindungen abrufen, wenn Sie Werte für Substitutionsvariablen definieren.
- Filter (optional): Sie können eine Regel innerhalb eines Triggers erstellen, die festlegt, ob der Trigger einen Build auf der Grundlage Ihrer Substitutionsvariablen ausführt.
Klicken Sie auf Erstellen, um den Build-Trigger zu erstellen.

gcloud

So erstellen Sie einen Webhook-Trigger:

gcloud builds triggers create webhook \
  --trigger-config=TRIGGER_CONFIG_PATH \
  --name=TRIGGER_NAME \
  --description=DESCRIPTION \
  --region=REGION \
  --secret=projects/PROJECT_ID/secrets/SECRET_NAME/versions/SECRET_VERSION \
  --service-account=SERVICE_ACCOUNT \ 
  --repository=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/repositories/REPO_NAME \ 
  --build-config=PATH_TO_BUILD_CONFIG \
  --inline-config=PATH_TO_INLINE_BUILD_CONFIG \
  --dockerfile=DOCKERFILE \
  --dockerfile-dir=DOCKERFILE_DIR \
  --dockerfile-image=DOCKERFILE_IMAGE \
  --tag=TAG_NAME \
  --branch=BRANCH_NAME \
  --substitutions=_SUB_ONE=SUBSTITUTION \
  --subscription-filter=FILTER \
  --require-approval

Wobei:

TRIGGER_CONFIG_PATH ist der Pfad zu einer Trigger-Konfigurationsdatei. Wenn Sie eine Trigger-Konfigurationsdatei verwenden, müssen die Felder name, description, region, secret, service-account, subscription-filter und substitution undefiniert bleiben. Weitere Informationen finden Sie in der Cloud Build-Referenzdokumentation unter BuildTrigger.
TRIGGER_NAME ist der Name des Triggers.
DESCRIPTION (optional) ist eine Beschreibung für Ihren Trigger.
REGION ist die Region für Ihren Trigger. Dieser Wert muss eine andere Region als „global“ sein.
SECRET_NAME ist der Name des Secrets, wie es im Secret Manager gespeichert ist.
SECRET_VERSION ist die Version, die mit Ihrem Secret verknüpft ist, wie es in Secret Manager gespeichert ist.
SERVICE_ACCOUNT ist das Dienstkonto, das zum Ausführen aller nutzergesteuerten Vorgänge im Zusammenhang mit Ihrem Build-Trigger verwendet wird. Wenn Sie kein Dienstkonto definieren, verwendet Cloud Build das Cloud Build-Standarddienstkonto.
PROJECT_ID ist die Google Cloud Projekt-ID.
CONNECTION_NAME ist der Name Ihrer Hostverbindung.
REPO_NAME ist der Name Ihres Repositorys.
PATH_TO_BUILD_CONFIG ist der Pfad zu einer Build-Konfigurationsdatei. Verwenden Sie diesen Parameter, wenn sich Ihr Trigger auf eine Build-Konfigurationsdatei in einem Cloud Build-Repository bezieht. Wenn Sie diesen Parameter festlegen, können Sie kein inline-config definieren oder Parameter für ein Dockerfile verwenden.
PATH_TO_INLINE_BUILD_CONFIG ist der Pfad zu einer Inline-Build-Konfiguration. Verwenden Sie diesen Parameter, wenn sich der Trigger auf eine lokale Build-Konfigurationsdatei bezieht. Wenn Sie diesen Parameter festlegen, können Sie keine build-config definieren oder Parameter für ein Dockerfile verwenden.
DOCKERFILE ist der Pfad zu einem Dockerfile. Verwenden Sie diesen Parameter, wenn sich Ihr Trigger auf ein Dockerfile bezieht. Wenn Sie Dockerfile-Parameter festlegen, können Sie keinen build-config oder inline-config definieren.
DOCKERFILE_DIR ist das Verzeichnis des Dockerfile.
DOCKERFILE_IMAGE ist der Name des Docker-Images, das von Cloud Build erstellt wird.
BRANCH_NAME ist der Name Ihres Zweigs, wenn Sie den Trigger auf einem Zweig erstellen möchten. Wenn Sie diesen Parameter festlegen, können Sie keine tag definieren.
TAG_NAME ist der Name Ihres Tags, wenn Sie den Trigger auf einem Tag aufbauen möchten. Wenn Sie diesen Parameter festlegen, können Sie keine branch definieren.
SUBSTITUTION (optional) sind Parameter, die in der Build-Spezifikation ersetzt werden sollen. Beispiel: _SUB_ONE='$(body.message.test)',_SUB_TWO='$(body.message.output)'
FILTER (Optional) ist ein CEL-Filterausdruck für den Trigger, z. B. '_SUB_ONE == "prod"'.
(Optional) Wenn --require-approval im Befehl vorhanden ist, ist für ausgelöste Builds in Cloud Build eine manuelle Genehmigung erforderlich.

Webhook-Ereignis aufrufen

Verwenden Sie den folgenden Befehl, um ein Webhook-Ereignis aufzurufen:

curl -X POST -H "Content-type: application/json" "https://cloudbuild.googleapis.com/v1/projects/${PROJECT_ID}/locations/${REGION}/triggers/${TRIGGER_NAME}:webhook?key=${API_KEY}&secret=${SECRET_VALUE}&trigger=${TRIGGER_NAME}&projectId=${PROJECT_ID}" -d "{}"

(Optional) Dienstkonto die Rolle Secret Manager zuweisen

Wenn Sie Ihr Secret beim Erstellen des Webhook-Triggers konfigurieren, weist Cloud Build Dienstkonten, die diese Rolle benötigen, in den meisten Fällen automatisch die Rolle Zugriffsperson für Secret Manager-Secret zu. Wenn Sie ein vorhandenes Secret verwenden, müssen Sie dem Cloud Build-Dienstkonto möglicherweise auch manuell die Rolle „Zugriffsperson für Secret Manager-Secret“ zuweisen:

Öffnen Sie in der Google Cloud Console die Seite „IAM“:

Seite "IAM" öffnen
Optional: Wenn Sie von Google bereitgestellte Konten sehen möchten, klicken Sie das Kästchen Von Google bereitgestellte Rollenzuweisungen einschließen an.
Notieren Sie sich das Build-Dienstkonto, dem Sie die Rolle zuweisen möchten.
Öffnen Sie in der Google Cloud Console die Seite Secret Manager:

Zur Seite "Secret Manager"
Klicken Sie auf den Namen Ihres Secrets.

Es wird die Seite Secret-Details angezeigt.
1. Klicken Sie auf den Tab Berechtigungen.
2. Klicken Sie auf Zugriff erlauben.
  
  Der Bereich Zugriff erlauben wird angezeigt.
3. Fügen Sie im Bereich Hauptkonten hinzufügen die E-Mail-Adresse hinzu, die dem Build-Dienstkonto zugeordnet ist.
4. Wählen Sie im Abschnitt Rollen zuweisen die Option Secret Manager > Zugriffsperson für Secret Manager-Secret aus.
5. Klicken Sie auf Speichern.

(Optional) API-Schlüssel abrufen

Zur Authentifizierung eines eingehenden Webhook-Ereignisses benötigen Sie einen API-Schlüssel. Dieser API-Schlüssel ist Teil des geheimen Schlüssels, den Sie beim Konfigurieren des Webhook-Triggers auswählen. Wenn Sie noch keinen API-Schlüssel haben oder Cloud Build beim Konfigurieren Ihres Secrets in der Google Cloud Konsole keinen abrufen konnte, können Sie einen API-Schlüssel manuell erstellen:

So erhalten Sie einen API-Schlüssel:

Öffnen Sie in der Google Cloud Console die Seite Anmeldedaten:

Öffnen Sie die Seite Anmeldedaten
Klicken Sie auf Anmeldedaten erstellen.
Klicken Sie auf API-Schlüssel.

Es wird ein Dialogfeld mit Ihrem erstellten API-Schlüssel angezeigt. Notieren Sie sich Ihren API-Schlüssel.
Wenn Sie Ihren Schlüssel für Produktanwendungen einschränken möchten, klicken Sie auf Schlüssel einschränken, um weitere Schritte zum Schutz Ihres Schlüssels auszuführen. Klicken Sie ansonsten auf Schließen.

Informationen zum Einschränken Ihres Schlüssels finden Sie unter Einschränkungen für API-Schlüssel anwenden.