Mit Cloud Build Pub/Sub-Triggern können Sie Builds als Reaktion auf Google Cloud-Ereignisse ausführen, die über Pub/Sub veröffentlicht wurden. Sie können Informationen aus einem Pub/Sub-Ereignis verwenden, um Ihren Build zu parametrisieren und zu entscheiden, ob ein Build als Reaktion auf das Ereignis ausgeführt werden soll. Pub- und Sub-Trigger können so konfiguriert werden, dass sie jedes Pub/Sub-Thema überwachen.
Auf dieser Seite wird erklärt, wie Sie einen Pub/Sub-Trigger erstellen können, der als Reaktion auf Ereignisse in Artifact Registry, Container Registry und Cloud Storage erstellt wird.
Hinweis
-
Cloud Build API aktivieren.
- Achten Sie darauf, dass Ihr Quellcode im Repository eine Build-Konfigurationsdatei oder eine
Dockerfile
enthält. Wenn Sie
gcloud
-Befehle auf dieser Seite verwenden möchten, installieren Sie die Google Cloud-Befehlszeile.
Build-Trigger erstellen, der auf Artifact Registry-Ereignisse reagiert
Sie können einen Pub/Sub-Trigger erstellen, der auf Artifact Registry-Ereignisse reagiert, z. B. wenn Images hochgeladen, getaggt oder gelöscht werden. In diesem Abschnitt wird erläutert, wie Sie einen Pub/Sub-Trigger erstellen, der einen Build aufruft, wenn ein neues Tag in ein vorhandenes Image übertragen wird. Informationen zu Artifact Registry finden Sie in der Artifact Registry-Übersicht.
Console
So erstellen Sie einen Trigger, der über die Google Cloud Console auf ein neues Tag wartet, das an ein vorhandenes Image in Artifact Registry gesendet wird:
Seite "Trigger" aufrufen
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: Geben Sie einen Namen für den Trigger ein.
- Region: Wählen Sie die Region für den Trigger aus. Hinweis: Wenn Sie global als Region auswählen, werden Standardpools zum Ausführen Ihres Builds verwendet. Andernfalls wird ein privater Pool in der Region Ihres Triggers verwendet, um Ihren Build auszuführen.
- Beschreibung (Optional): Geben Sie eine Beschreibung für den Trigger ein.
- Ereignis: Wählen Sie Pub/Sub-Nachricht als das Ereignis, das Ihren Trigger auslösen soll.
Abo: Wählen Sie das Pub/Sub-Thema aus, das Sie als Trigger-Ereignis abonnieren möchten. Sie sehen alle vorhandenen Themen in Ihrem Projekt im Drop-down-Menü.
- Pub/Sub-Thema: Wählen Sie das Thema
gcr
aus dem Drop-Down-Menü aus oder erstellen Sie das Thema manuell anhand der Anweisungen unter Pub/Sub-Benachrichtigungen konfigurieren.
- Pub/Sub-Thema: Wählen Sie das Thema
Quelle: Wählen Sie das Repository aus, das bei Ausführung des Triggers erstellt werden soll.
Revision: Wählen Sie den Zweig oder das Tag aus, der oder das erstellt werden soll, wenn der Trigger ausgeführt wird.
- Zweig: Geben Sie den Namen des Zweigs ein, in dem der Build aufgerufen werden soll.
- Tag: Geben Sie den Namen des Tags ein, auf dem Ihr Build aufgerufen werden soll.
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.
- 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 eineDockerfile
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 derDockerfile
oder des Buildpacks angegeben haben, sehen Sie eine Vorschau des Befehlsdocker build
oderpack
, 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 der Google Cloud Console mit YAML- oder JSON-Syntax zu schreiben. Klicken Sie auf Fertig, um die Build-Konfiguration zu speichern.
- Repository: Wenn sich Ihre Konfigurationsdatei in Ihrem Remote-Repository befindet, geben Sie den Speicherort Ihrer Build-Konfigurationsdatei, das Verzeichnis der
- Typ: Wählen Sie den Konfigurationstyp aus, der für Ihren Build verwendet werden soll.
Substitutionen (Optional): Wenn Sie die Build-Konfigurationsdatei als Build-Konfigurationsoption gewählt haben, können Sie in diesem Feld trigger-spezifische Substitutionsvariablen definieren.
Im folgenden Beispiel möchten wir den Namen des Image-Tags aus der Nutzlast und der mit dem Ereignis
gcr
verknüpften Aktion abrufen. Erstellen Sie dazu Substitutionsvariablen mithilfe von Nutzlastbindungen.Geben Sie unten die folgenden Variablen und Werte an:
Variablenname Variablenwert: _IMAGE_TAG
$(body.message.data.tag)
_ACTION
$(body.message.data.action)
body.message
verweist auf die PubSubMessage, die von Publishern veröffentlicht und von Abonnenten genutzt wird. Weitere Beispiele zur Nutzlast der Pub/Sub-Benachrichtigungen finden Sie unter Benachrichtigungsbeispiele.Filter (optional): Sie können Filter innerhalb eines Triggers erstellen, um zu bestimmen, ob Ihr Trigger als Reaktion auf die eingehende Nutzlast einen Build ausführt. Geben Sie dazu Filter für Substitutionsvariablen an. Der Filterausdruck muss
true
ergeben, damit ein Build ausgeführt wird.Wir empfehlen die Verwendung von Filtern, wenn Sie Pub/Sub-Trigger für Themen mit mehreren Nachrichten einrichten. Mit Filtern können Sie Builds genau steuern, die als Reaktion auf eingehende Pub/Sub-Nachrichten ausgeführt werden. Informationen zu Risiken, die mit der Einrichtung eines Triggers ohne Filter verbunden sind, finden Sie unter Risiken, die mit einem ungefilterten Trigger verknüpft sind.
Im folgenden Beispiel soll der Trigger einen Build ausführen, wenn ein neues Tag in ein vorhandenes Image übertragen wird. Wir verwenden Filterbedingungsoperatoren, um zu prüfen, ob die Variable
_IMAGE_TAG
mit einem vorhandenen Tag-Namen übereinstimmt und ob die Variable_ACTION
mitINSERT
übereinstimmt, um neu hinzugefügte Daten zu suchen.Geben Sie Folgendes als Filter an:
_IMAGE_TAG
!=""
_ACTION
==INSERT
Die Filtersyntax in Pub/Sub-Triggern verwendet die CEL (Common Expression Language) zur Ausdrucksbewertung. Weitere Informationen zu CEL finden Sie im Repository cel-spec. Weitere Beispiele für Filtersyntaxen, die Sie auf Ihre Pub/Sub-Trigger anwenden können, finden Sie unter CEL zum Filtern von Build-Ereignissen verwenden.
- Klicken Sie auf Erstellen, um den Trigger zu erstellen. .
gcloud
So erstellen Sie einen Trigger, der auf ein neues Tag wartet, das mithilfe der gcloud
-Befehle an ein bestehendes Image in Artifact Registry angehängt wird:
- Öffnen Sie ein Terminalfenster.
Führen Sie den Befehl
gcloud alpha
aus, um in Ihrem Projekt einen Build-Trigger zu erstellen. Im folgenden Beispiel ist der Trigger so konfiguriert, dass er auf Builds mit einem Tag, das mitprod
übereinstimmt, und einer Aktion, die mitINSERT
übereinstimmt, auf der Grundlage der angegebenen Nutzlast reagiert, die durch die Substitutionsvariable_IMAGE_TAG
definiert ist.gcloud alpha builds triggers create pubsub \ --name=TRIGGER_NAME \ --topic=projects/PROJECT_ID/topics/TOPIC_NAME \ --build-config=BUILD_CONFIG \ # or --inline-config=INLINE_BUILD_CONFIG --substitutions=\ _IMAGE_TAG_='$(body.message.data.tag)' _ACTION='$(body.message.data.action)' --filter='_IMAGE_TAG == "" && _ACTION == "INSERT"' --repo=REPO_NAME --tag=TAG_NAME # or --branch=BRANCH_NAME
Dabei gilt:
- TRIGGER_NAME ist der Name des Triggers.
- PROJECT_ID ist die ID Ihres Cloud-Projekts.
- TOPIC_NAME ist der Name des Pub/Sub-Themas, das Sie abonniert haben.
- BUILD_CONFIG ist der Pfad zu Ihrer Build-Konfigurationsdatei.
- INLINE_BUILD_CONFIG ist der Pfad zu Ihrer Inline-Build-Konfigurationsdatei.
- REPO_NAME ist der Name des Quell-Repositorys, in dem der Build aufgerufen wird.
- TAG_NAME ist der Name Ihres Tags, wenn Sie den Trigger auf einem Tag aufbauen möchten.
- BRANCH_NAME ist der Name Ihres Zweigs, wenn Sie den Trigger auf einem Zweig erstellen möchten.
Build-Trigger erstellen, der auf Container Registry-Ereignisse reagiert
Sie können einen Pub/Sub-Trigger erstellen, der auf Container Registry-Ereignisse reagiert, z. B. wenn Images hochgeladen, getaggt oder gelöscht werden. In diesem Abschnitt wird beschrieben, wie Sie einen Pub/Sub-Trigger erstellen können, der einen Build auslöst, wenn ein Image einem von einem benutzerdefinierten Filter festgelegten Tag entspricht. Wenn Sie mit Container Registry nicht vertraut sind, finden Sie in der Container Registry – Kurzanleitung Informationen zum Hoch- und Herunterladen von Images mit Tags.
Console
So erstellen Sie einen Trigger, der in Container Registry einen Image-Push-Vorgang überwacht und anhand des Tag-Namens über die Google Cloud Console übereinstimmt:
Seite "Trigger" aufrufen
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: Geben Sie einen Namen für den Trigger ein.
- Region: Wählen Sie die Region für den Trigger aus. Hinweis: Wenn Sie global als Region auswählen, werden Standardpools zum Ausführen Ihres Builds verwendet. Andernfalls wird ein privater Pool in der Region Ihres Triggers verwendet, um Ihren Build auszuführen.
- Beschreibung (Optional): Geben Sie eine Beschreibung für den Trigger ein.
- Ereignis: Wählen Sie Pub/Sub-Nachricht als das Ereignis, das Ihren Trigger auslösen soll.
Abo: Wählen Sie das Pub/Sub-Thema aus, das Sie als Trigger-Ereignis abonnieren möchten. Sie sehen alle vorhandenen Themen in Ihrem Projekt im Drop-down-Menü.
- Pub/Sub-Thema: Wählen Sie das Thema
gcr
aus dem Drop-Down-Menü aus oder erstellen Sie das Thema manuell anhand der Anweisungen unter Pub/Sub-Benachrichtigungen konfigurieren.
- Pub/Sub-Thema: Wählen Sie das Thema
Quelle: Wählen Sie das Repository aus, das bei Ausführung des Triggers erstellt werden soll.
Revision: Wählen Sie den Zweig oder das Tag aus, der oder das erstellt werden soll, wenn der Trigger ausgeführt wird.
- Zweig: Geben Sie den Namen des Zweigs ein, in dem der Build aufgerufen werden soll.
- Tag: Geben Sie den Namen des Tags ein, auf dem Ihr Build aufgerufen werden soll.
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.
- 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 eineDockerfile
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 derDockerfile
oder des Buildpacks angegeben haben, sehen Sie eine Vorschau des Befehlsdocker build
oderpack
, 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 der Google Cloud Console mit YAML- oder JSON-Syntax zu schreiben. Klicken Sie auf Fertig, um die Build-Konfiguration zu speichern.
- Repository: Wenn sich Ihre Konfigurationsdatei in Ihrem Remote-Repository befindet, geben Sie den Speicherort Ihrer Build-Konfigurationsdatei, das Verzeichnis der
- Typ: Wählen Sie den Konfigurationstyp aus, der für Ihren Build verwendet werden soll.
Substitutionen (Optional): Wenn Sie die Build-Konfigurationsdatei als Build-Konfigurationsoption gewählt haben, können Sie in diesem Feld trigger-spezifische Substitutionsvariablen definieren.
Im folgenden Beispiel möchten wir den Namen des Image-Tags aus der Nutzlast und der mit dem Ereignis
gcr
verknüpften Aktion abrufen. Erstellen Sie dazu Substitutionsvariablen mithilfe von Nutzlastbindungen.Geben Sie unten die folgenden Variablen und Werte an:
Variablenname Variablenwert: _IMAGE_TAG
$(body.message.data.tag)
_ACTION
$(body.message.data.action)
body.message
verweist auf die PubSubMessage, die von Publishern veröffentlicht und von Abonnenten genutzt wird. Weitere Beispiele zur Nutzlast der Pub/Sub-Benachrichtigungen finden Sie unter Benachrichtigungsbeispiele.Filter (optional): Sie können Filter innerhalb eines Triggers erstellen, um zu bestimmen, ob Ihr Trigger als Reaktion auf die eingehende Nutzlast einen Build ausführt. Geben Sie dazu Filter für Substitutionsvariablen an. Der Filterausdruck muss
true
ergeben, damit ein Build ausgeführt wird.Wir empfehlen die Verwendung von Filtern, wenn Sie Pub/Sub-Trigger für Themen mit mehreren Nachrichten einrichten. Mit Filtern können Sie Builds genau steuern, die als Reaktion auf eingehende Pub/Sub-Nachrichten ausgeführt werden. Informationen zu Risiken, die mit der Einrichtung eines Triggers ohne Filter verbunden sind, finden Sie unter Risiken, die mit einem ungefilterten Trigger verknüpft sind.
Im folgenden Beispiel soll der Trigger einen Build ausführen, wenn der Name der Tag-Variable
_IMAGE_TAG
mit einem bestimmten Tag-Namen wieprod
übereinstimmt. Sie können den Operator "Filterbedingung" mit "==" für genaue Übereinstimmung angeben. Sie können auch nach der Aktion suchen, die mit Ihrem Ereignisgcr
verknüpft ist. Sie können beispielsweise_ACTION
istINSERT
angeben, um nach neu hinzugefügten Daten zu suchen.Geben Sie Folgendes als Filter an:
_IMAGE_TAG
==prod
_ACTION
==INSERT
Die Filtersyntax in Pub/Sub-Triggern verwendet die CEL (Common Expression Language) zur Ausdrucksbewertung. Weitere Informationen zu CEL finden Sie im Repository cel-spec. Weitere Beispielsyntaxen zum Filtern, die Sie auf Pub/Sub-Trigger anwenden können, finden Sie unter Builds filtern.
- Klicken Sie auf Erstellen, um den Trigger zu erstellen. .
gcloud
So erstellen Sie einen Trigger, der auf eine Image-Übertragung in der Container-Registry wartet und auf der Grundlage eines Tag-Namens mit gcloud
-Befehlen zuordnet:
- Öffnen Sie ein Terminalfenster.
Führen Sie den Befehl
gcloud alpha
aus, um in Ihrem Projekt einen Build-Trigger zu erstellen. Im folgenden Beispiel ist der Trigger so konfiguriert, dass er auf Builds mit einem Tag, das mitprod
übereinstimmt, und einer Aktion, die mitINSERT
übereinstimmt, auf der Grundlage der angegebenen Nutzlast reagiert, die durch die Substitutionsvariable_IMAGE_TAG
definiert ist.gcloud alpha builds triggers create pubsub \ --name=TRIGGER_NAME \ --topic=projects/PROJECT_ID/topics/TOPIC_NAME \ --build-config=BUILD_CONFIG \ # or --inline-config=INLINE_BUILD_CONFIG --substitutions=\ _IMAGE_TAG_='$(body.message.data.tag)' _ACTION='$(body.message.data.action)' --filter='_IMAGE_TAG == "prod" && _ACTION == "INSERT"' --repo=REPO_NAME --tag=TAG_NAME # or --branch=BRANCH_NAME
Dabei gilt:
- TRIGGER_NAME ist der Name des Triggers.
- PROJECT_ID ist die ID Ihres Cloud-Projekts.
- TOPIC_NAME ist der Name des Pub/Sub-Themas, das Sie abonniert haben.
- BUILD_CONFIG ist der Pfad zu Ihrer Build-Konfigurationsdatei.
- INLINE_BUILD_CONFIG ist der Pfad zu Ihrer Inline-Build-Konfigurationsdatei.
- REPO_NAME ist der Name des Quell-Repositorys, in dem der Build aufgerufen wird.
- TAG_NAME ist der Name Ihres Tags, wenn Sie den Trigger auf einem Tag aufbauen möchten.
- BRANCH_NAME ist der Name Ihres Zweigs, wenn Sie den Trigger auf einem Zweig erstellen möchten.
Build-Trigger erstellen, der auf Cloud Storage-Ereignisse reagiert
Sie können einen Pub/Sub-Trigger erstellen, der auf Cloud Storage-Ereignisse reagiert, z. B. wenn eine neue Binärdatei in einen vorhandenen Storage-Bucket übertragen wird. In diesem Abschnitt wird erläutert, wie Sie einen Pub/Sub-Trigger erstellen, der beim Bereitstellen einer neuen Binärdatei in einem hochgeladenen Bucket mit einem Build antwortet. Wenn Sie nicht mit Cloud Storage vertraut sind, lesen Sie die Kurzanleitungen.
Console
So erstellen Sie einen Trigger, der Cloud Storage-Ereignisse über die Google Cloud Console überwacht:
Seite "Trigger" aufrufen
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: Geben Sie einen Namen für den Trigger ein.
- Region: Wählen Sie die Region für den Trigger aus. Hinweis: Wenn Sie global als Region auswählen, werden Standardpools zum Ausführen Ihres Builds verwendet. Andernfalls wird ein privater Pool in der Region Ihres Triggers verwendet, um Ihren Build auszuführen.
- Beschreibung (Optional): Geben Sie eine Beschreibung für den Trigger ein.
- Ereignis: Wählen Sie Pub/Sub-Nachricht als das Ereignis, das Ihren Trigger auslösen soll.
Abo: Wählen Sie das Pub/Sub-Thema aus, das Sie als Trigger-Ereignis abonnieren möchten. Sie sehen alle vorhandenen Themen in Ihrem Projekt im Drop-down-Menü.
- Pub/Sub-Thema: Wählen Sie das Thema
gcs
aus dem Drop-Down-Menü aus oder erstellen Sie das Thema manuell anhand der Anweisungen unter Pub/Sub-Benachrichtigungen für Cloud Storage.
- Pub/Sub-Thema: Wählen Sie das Thema
Quelle: Wählen Sie das Repository aus, das bei Ausführung des Triggers erstellt werden soll.
Revision: Wählen Sie den Zweig oder das Tag aus, der oder das erstellt werden soll, wenn der Trigger ausgeführt wird.
- Zweig: Geben Sie den Namen des Zweigs ein, in dem der Build aufgerufen werden soll.
- Tag: Geben Sie den Namen des Tags ein, auf dem Ihr Build aufgerufen werden soll.
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.
- 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 eineDockerfile
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 derDockerfile
oder des Buildpacks angegeben haben, sehen Sie eine Vorschau des Befehlsdocker build
oderpack
, 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 der Google Cloud Console mit YAML- oder JSON-Syntax zu schreiben. Klicken Sie auf Fertig, um die Build-Konfiguration zu speichern.
- Repository: Wenn sich Ihre Konfigurationsdatei in Ihrem Remote-Repository befindet, geben Sie den Speicherort Ihrer Build-Konfigurationsdatei, das Verzeichnis der
- Typ: Wählen Sie den Konfigurationstyp aus, der für Ihren Build verwendet werden soll.
Substitutionen (Optional): Wenn Sie die Build-Konfigurationsdatei als Build-Konfigurationsoption gewählt haben, können Sie in diesem Feld trigger-spezifische Substitutionsvariablen definieren.
In diesem Beispiel möchten wir nach der Bereitstellung einer neuen Binärdatei suchen, wenn diese in einen Bucket hochgeladen wird. Zum Abrufen dieser Daten können wir Substitutionsvariablen mithilfe von Nutzlastbindungen erstellen.
Geben Sie unten die folgenden Variablen und Werte an:
Variablenname Variablenwert: _EVENT_TYPE
$(body.message.attributes.eventType)
_BUCKET_ID
$(body.message.attributes.bucketId)
_OBJECT_ID
$(body.message.attributes.objectId)
body.message
verweist auf die PubSubMessage, die von Publishern veröffentlicht und von Abonnenten genutzt wird. Weitere Beispiele zur Nutzlast der Pub/Sub-Benachrichtigungen finden Sie unter Benachrichtigungsbeispiele.Filter (optional): Sie können Filter innerhalb eines Triggers erstellen, um zu bestimmen, ob Ihr Trigger als Reaktion auf die eingehende Nutzlast einen Build ausführt. Geben Sie dazu Filter für Substitutionsvariablen an. Der Filterausdruck muss
true
ergeben, damit ein Build ausgeführt wird.Wir empfehlen die Verwendung von Filtern, wenn Sie Pub/Sub-Trigger für Themen mit mehreren Nachrichten einrichten. Mit Filtern können Sie Builds genau steuern, die als Reaktion auf eingehende Pub/Sub-Nachrichten ausgeführt werden. Informationen zu Risiken, die mit der Einrichtung eines Triggers ohne Filter verbunden sind, finden Sie unter Risiken, die mit einem ungefilterten Trigger verknüpft sind.
Da der Trigger einen Build ausführen soll, wenn die neue Binärdatei in einem bestimmten Bucket bereitgestellt wurde, können wir mit dem Operator "==" nach genauen Übereinstimmungen suchen. Sie können auch das Keyword "matches" verwenden, wenn Sie nach regulären Ausdrücken suchen möchten.
Geben Sie Folgendes als Filter an:
_EVENT_TYPE
==OBJECT_FINALIZE
_OBJECT_ID
matches^<object-id>$
_BUCKET_ID
matches^<bucket-id>$
- Klicken Sie auf Erstellen, um den Trigger zu erstellen. .
gcloud
So erstellen Sie einen Build-Trigger, der Build-Ereignisse mit einem bestimmten Ereignistyp in Cloud Storage überwacht:
- Öffnen Sie ein Terminalfenster.
Führen Sie den Befehl
gcloud alpha
aus, um in Ihrem Projekt einen Build-Trigger zu erstellen. Im folgenden Beispiel ist der Trigger so konfiguriert, dass er auf Builds mit einem Cloud Storage-Ereignis antwortet, das einer neuen Binärdatei zugeordnet ist, die an einen vorhandenen Storage-Bucket übertragen wird:gcloud alpha builds triggers create pubsub \ --name=TRIGGER_NAME \ --topic=projects/PROJECT_ID/topics/TOPIC_NAME \ --build-config=BUILD_CONFIG \ # or --inline-config=INLINE_BUILD_CONFIG --substitutions=\ _EVENT_TYPE='$(body.message.attributes.eventType)' _BUCKET_ID='$(body.message.attributes.bucketId)' _OBJECT_ID='$(body.message.attributes.objectId)' --filter='_EVENT_TYPE == "OBJECT_FINALIZE" && _OBJECT_ID.matches("<object-id>") && _BUCKET_ID.matches("<bucket-id>")' --repo=REPO_NAME --tag=TAG_NAME # or --branch=BRANCH_NAME
Dabei gilt:
- TRIGGER_NAME ist der Name des Triggers.
- PROJECT_ID ist die ID Ihres Cloud-Projekts.
- TOPIC_NAME ist der Name des Pub/Sub-Themas, das Sie abonniert haben.
- BUILD_CONFIG ist der Pfad zu Ihrer Build-Konfigurationsdatei.
- INLINE_BUILD_CONFIG ist der Pfad zu Ihrer Inline-Build-Konfigurationsdatei.
- REPO_NAME ist der Name des Quell-Repositorys, in dem der Build aufgerufen wird.
- TAG_NAME ist der Name Ihres Tags, wenn Sie den Trigger auf einem Tag aufbauen möchten.
- BRANCH_NAME ist der Name Ihres Zweigs, wenn Sie den Trigger auf einem Zweig erstellen möchten.
Risiken, die mit einem ungefilterten Trigger verbunden sind
Wenn Sie keine Filter für Ihren Pub/Sub-Trigger konfiguriert haben, kann es passieren, dass Ihr Trigger eine unendliche Anzahl von Builds aufruft, wenn Ihr Trigger ein Artefakt oder Objekt ändert, das unbeabsichtigt eine neue Nachricht in dem Topic veröffentlicht, das es überwacht. Beispielsweise kann Ihr Trigger eine unbegrenzte Anzahl von Builds auslösen, wenn Ihr Trigger:
- Auf ein
gcr
-Thema verweist. - Ein beliebiges Image oder Tag in
gcr
erstellt. - Auf ein
gcs
-Thema für ein bestimmtes Objekt in Ihrem Bucket verweist und dieses Objekt ändert.
Bei einer Endlosschleife können Sie den Trigger löschen oder aktualisieren, sodass er auf ein separates Thema verweist. So vermeiden Sie, dass für jeden aufgerufenen Build zusätzliche Gebühren anfallen.
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, die dem Feld zugeordnet ist, finden Sie in der Datei cloudbuild.proto
.
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 Container Registry aufgeführt, z. B. gcr.io/example/image-one
:
filter: image-name in build.images
Im folgenden Beispiel filtert filter
nach Build-Ereignissen, in denen entweder gcr.io/example/image-one
oder gcr.io/example/image-two
als Bildnamen angegeben ist:
filter: "gcr.io/example/image-one" in build.images || "gcr.io/example/image-two" 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
Dabei 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.
Weitere Informationen
- Builds manuell starten mit
gcloud
-Befehlen oder der Cloud Build API. - Trigger erstellen und verwalten
- Build-Ergebnisse aufrufen
- Build-Fehler beheben