Pub/Sub-Trigger erstellen

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

  • Aktivieren Sie die Cloud Build API.

    Aktivieren Sie die API

  • Achten Sie darauf, dass Ihr Quellcode im Repository eine Build-Konfigurationsdatei oder eine Dockerfile enthält.

  • Installieren Sie das Cloud SDK, um gcloud-Befehle auf dieser Seite zu verwenden.

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. Wenn Sie mit Artifact Registry nicht vertraut sind, lesen Sie Artefaktverwaltung – Übersicht.

Console

So erstellen Sie einen Trigger, der ein neues Tag überwacht, das über die Google Cloud Console auf ein vorhandenes Image in Artifact Registry übertragen wird:

  1. Seite "Trigger" aufrufen

    Seite "Trigger" aufrufen

  2. Wählen Sie das Projekt oben auf der Seite aus und klicken Sie auf Öffnen.

  3. Klicken Sie auf Trigger erstellen.

  4. Geben Sie die folgenden Triggereinstellungen ein:

    • Name: Geben Sie einen Namen für den Trigger ein.
    • 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ü.

    • 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 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 der YAML- oder JSON-Syntax in der Google Cloud Console zu schreiben. Klicken Sie auf Fertig, um die Build-Konfiguration zu speichern.

    • 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 mit INSERT ü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.

  1. Klicken Sie auf Erstellen, um den Trigger zu erstellen.
    2. .

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:

  1. Öffnen Sie ein Terminalfenster.

  2. 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 mit prod übereinstimmt, und einer Aktion, die mit INSERT ü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

    Wobei:

    • 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 auf eine Image-Übertragung in Container Registry wartet und auf der Grundlage eines Tag-Namens über die Google Cloud Console zuordnet:

  1. Seite "Trigger" aufrufen

    Seite "Trigger" aufrufen

  2. Wählen Sie das Projekt oben auf der Seite aus und klicken Sie auf Öffnen.

  3. Klicken Sie auf Trigger erstellen.

  4. Geben Sie die folgenden Triggereinstellungen ein:

    • Name: Geben Sie einen Namen für den Trigger ein.
    • 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ü.

    • 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 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 der YAML- oder JSON-Syntax in der Google Cloud Console zu schreiben. Klicken Sie auf Fertig, um die Build-Konfiguration zu speichern.

    • 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 wie prod übereinstimmt. Sie können den Operator "Filterbedingung" mit "==" für genaue Übereinstimmung angeben. Sie können auch nach der Aktion suchen, die mit Ihrem Ereignis gcr verknüpft ist. Sie können beispielsweise _ACTION ist INSERT 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 Beispielsyntax für das Filtern, die Sie auf Ihre Pub/Sub-Trigger anwenden können, finden Sie unter Builds filtern.

  1. Klicken Sie auf Erstellen, um den Trigger zu erstellen.
    2. .

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:

  1. Öffnen Sie ein Terminalfenster.

  2. 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 mit prod übereinstimmt, und einer Aktion, die mit INSERT ü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

    Wobei:

    • 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 mit der Google Cloud Console überwacht:

  1. Seite "Trigger" aufrufen

    Seite "Trigger" aufrufen

  2. Wählen Sie das Projekt oben auf der Seite aus und klicken Sie auf Öffnen.

  3. Klicken Sie auf Trigger erstellen.

  4. Geben Sie die folgenden Triggereinstellungen ein:

    • Name: Geben Sie einen Namen für den Trigger ein.
    • 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ü.

    • 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 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 der YAML- oder JSON-Syntax in der Google Cloud Console zu schreiben. Klicken Sie auf Fertig, um die Build-Konfiguration zu speichern.

    • 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>$
  1. Klicken Sie auf Erstellen, um den Trigger zu erstellen.
    2. .

gcloud

So erstellen Sie einen Build-Trigger, der Build-Ereignisse mit einem bestimmten Ereignistyp in Cloud Storage überwacht:

  1. Öffnen Sie ein Terminalfenster.

  2. 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 mit einer neuen Binärdatei verknüpft ist, die in einen vorhandenen Storage-Bucket übertragen wurde:

     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

    Wobei:

    • 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

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.

Nächste Schritte