Builds als Reaktion auf Pub/Sub-Ereignisse automatisieren

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 Builds als Reaktion auf Ereignisse in Artifact Registry, Container Registry (veraltet) und Cloud Storage automatisiert.

Beschränkungen

Cloud Build Pub/Sub-Trigger werden nicht unterstützt, wenn VPC Service Controls wird verwendet.

Hinweise

  • Enable the Cloud Build API.

    Enable the API

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

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

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 den Hilfeartikel Artifact Registry – Übersicht.

Console

Um einen Trigger zu erstellen, der auf ein neues Tag wartet, das an einen Vorhandenes Image in Artifact Registry mit der Google Cloud Console:

  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.

    • Region: Wählen Sie die Region für den Trigger aus.

      • Wenn in der Build-Konfigurationsdatei, die mit dem Trigger verknüpft ist, ein privater Pool angegeben ist, verwendet Cloud Build den privaten Pool, um den Build auszuführen. 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 die mit dem Trigger verknüpfte Build-Konfigurationsdatei keinen privaten Pool angibt. Cloud Build verwendet die Standardeinstellung Pool, um den Build in derselben Region auszuführen als Trigger festlegen.

    • 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 die Quelle aus, die erstellt werden soll, wenn der Pub/Sub-Trigger ausgelöst wird. ausgeführt wird. Sie können 1. Generation oder 2. Generation als Quelle angeben.

      • Repository: Wählen Sie aus der Liste der verfügbaren Repositories das gewünschte Repository aus.

      • 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 (nur GitHub-App) als Ereignis ausgewählt haben, wählen Sie eine der folgenden Optionen aus, um zu kontrollieren, ob ein Build automatisch vom Trigger ausgeführt wird:

        • 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 vom Trigger 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. Kreationen werden bei jeder Änderung an einer Pull-Anfrage ausgeführt.

        • Nicht erforderlich: Wenn eine Pull-Anfrage von einem Mitwirkenden erstellt oder aktualisiert wird, werden Builds automatisch durch Trigger 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.

      • 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 die Konfigurationsdatei in der Remote-Repository, geben Sie den Speicherort Ihres Build-Konfigurationsdatei, die Dockerfile oder im Verzeichnis buildpacks. 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 Google Cloud Console in der YAML- oder JSON-Syntax 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.

  1. Klicken Sie auf Erstellen, um den Build-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:

  1. Öffnen Sie ein Terminalfenster.

  2. Führen Sie den Befehl gcloud 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 builds triggers create pubsub \
   --region=REGION \
   --name=TRIGGER_NAME \
   --repository=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/repositories/REPO_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)"' \
   --subscription-filter='_IMAGE_TAG == "" && _ACTION == "INSERT"' \
   --tag=TAG_NAME  # or --branch=BRANCH_NAME

Wobei:

  • REGION ist die Region für den Trigger.
  • TRIGGER_NAME ist der Name des Triggers.
  • PROJECT_ID ist die ID Ihres Cloud-Projekts.
  • CONNECTION_NAME ist der Name Ihrer Hostverbindung.
  • REPO_NAME ist der Name Ihres Repositorys.
  • 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.
  • 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.

    • Region: Wählen Sie die Region für den Trigger aus.

      • Wenn die mit dem Trigger verknüpfte Build-Konfigurationsdatei einen privaten Pool angibt, verwendet Cloud Build den privaten Pool, um Ihren Build auszuführen. In diesem Fall muss die im Trigger angegebene Region mit der Region übereinstimmen, in der Sie den privaten Pool erstellt haben.
      • Wenn die mit dem Trigger verknüpfte Build-Konfigurationsdatei keinen privaten Pool angibt. Cloud Build verwendet die Standardeinstellung Pool, um den Build in derselben Region auszuführen als Trigger festlegen.

    • 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 die Quelle aus, die bei Ausführung des Pub/Sub-Triggers erstellt werden soll. Sie können 1. Generation oder 2. Generation als Quelle angeben.

      • Repository: Wählen Sie aus der Liste der verfügbaren Repositories das gewünschte Repository aus.

      • 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 (nur GitHub-App) als Ereignis ausgewählt haben, wählen Sie eine der folgenden Optionen aus, um zu kontrollieren, ob ein Build automatisch vom Trigger ausgeführt wird:

        • 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 vom Trigger 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. Kreationen werden bei jeder Änderung an einer Pull-Anfrage ausgeführt.

        • Nicht erforderlich: Wenn eine Pull-Anfrage von einem Mitwirkenden erstellt oder aktualisiert wird, werden Builds automatisch durch Trigger 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.

      • 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 die Konfigurationsdatei in der Remote-Repository, geben Sie den Speicherort Ihres Build-Konfigurationsdatei, die Dockerfile oder im Verzeichnis buildpacks. 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 Google Cloud Console in der YAML- oder JSON-Syntax 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.matches(prod)
      • _ACTION.matches(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.

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

gcloud

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.

    • Region: Wählen Sie die Region für den Trigger aus.

      • Wenn die mit dem Trigger verknüpfte Build-Konfigurationsdatei einen privaten Pool angibt, verwendet Cloud Build den privaten Pool, um Ihren Build auszuführen. 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 die mit dem Trigger verknüpfte Build-Konfigurationsdatei keinen privaten Pool angibt. Cloud Build verwendet die Standardeinstellung Pool, um den Build in derselben Region auszuführen als Trigger festlegen.

    • 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 die Quelle aus, die erstellt werden soll, wenn der Pub/Sub-Trigger ausgelöst wird. ausgeführt wird. Sie können 1. Generation oder 2. Generation als Quelle angeben.

      • Repository: Wählen Sie aus der Liste der verfügbaren Repositories das gewünschte Repository aus.

      • 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 (nur GitHub-App) als Ereignis ausgewählt haben, wählen Sie eine der folgenden Optionen aus, um zu kontrollieren, ob ein Build automatisch vom Trigger ausgeführt wird:

        • 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 vom Trigger 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. Kreationen werden bei jeder Änderung an einer Pull-Anfrage ausgeführt.

        • Nicht erforderlich: Wenn eine Pull-Anfrage von einem Mitwirkenden erstellt oder aktualisiert wird, werden Builds automatisch durch Trigger 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.

      • 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 die Konfigurationsdatei in der Remote-Repository, geben Sie den Speicherort Ihres Build-Konfigurationsdatei, die Dockerfile oder im Verzeichnis buildpacks. 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 Google Cloud Console in der YAML- oder JSON-Syntax 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

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.

Nächste Schritte