Build-Trigger erstellen und verwalten

Ein Cloud Build-Trigger startet automatisch einen Build, wenn Sie Änderungen am Quellcode vornehmen. Sie können den Trigger so konfigurieren, dass Ihr Code bei allen Änderungen am Quell-Repository oder nur bei Änderungen, die bestimmten Kriterien entsprechen, erstellt wird.

Auf dieser Seite wird erläutert, wie Sie eine Verbindung zu Quell-Repositories wie GitHub und Bitbucket herstellen und Build-Trigger erstellen, um den Code in den Repositories zu erzeugen.

Hinweis

Damit die erforderlichen Berechtigungen zum Erstellen und Verwalten von Build-Triggern hat, bitten Sie Ihren Administrator, die IAM-Rolle Cloud Build Editor (roles/cloudbuild.builds.editor) für das Konto Ihres Projekts zuzuweisen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Ihr Administrator kann Ihnen die erforderlichen Berechtigungen möglicherweise auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erteilen.

Gehen Sie außerdem so vor:

• Aktivieren Sie die Cloud Build API, falls sie noch nicht aktiviert ist.

  Rollen, die zum Aktivieren von APIs erforderlich sind

  Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Rolle „Inhaber“ (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen

  API aktivieren

• Achten Sie darauf, dass Sie Quellcode in Cloud Source Repositories, GitHub oder Bitbucket haben.
• Sorgen Sie entweder für ein Dockerfile oder eine Cloud Build-Konfigurationsdatei.

Achtung:Seit dem 17. Juni 2024 ist Cloud Source Repositories nicht mehr für Neukunden verfügbar. Wenn Ihre Organisation noch nicht Cloud Source Repositories verwendet hat, können Sie die API nicht aktivieren oder Cloud Source Repositories verwenden. Für neue Projekte, die nicht mit einer Organisation verbunden sind, kann die Cloud Source Repositories API nicht aktiviert werden. Organisationen, die Cloud Source Repositories vor dem 17. Juni 2024 verwendet haben, sind von dieser Änderung nicht betroffen.

Mit Quell-Repositories verbinden

Sie müssen Cloud Build zuerst mit Ihrem Quell-Repository verbinden, bevor Sie den Code in diesem Repository erstellen. Ihre Cloud Source Repositories sind standardmäßig mit Cloud Build verbunden. Sie können Trigger für Ihre Repositories in Cloud Source Repositories direkt erstellen, ohne sie manuell zu verbinden.

Wenn Sie ein externes Repository verbinden, das z. B. auf GitHub oder Bitbucket gehostet wird, benötigen Sie Berechtigungen auf Administratorebene für das Repository, um Ihr Repository anfänglich mit Cloud Build zu verbinden. Administratorberechtigungen sind nicht erforderlich, um Trigger in einem Repository zu erstellen, das bereits mit Cloud Build verbunden ist.

Gehen Sie so vor, um eine Verbindung zu GitHub oder Bitbucket herzustellen:

1. Öffnen Sie in der Google Cloud Console die Seite Trigger.

   Zur Seite "Trigger"

2. Wählen Sie in der Symbolleiste der Google Cloud Console Ihr Projekt von Google Cloud aus.

3. Klicken Sie auf Repository verbinden.

4. Wählen Sie im Drop-down-Menü Region die Region aus, in der Sie den Trigger erstellen möchten.

   Hinweis :Wenn Sie global als Region auswählen, werden Standardpools verwendet, um den Build auszuführen. Andernfalls wird ein privater Pool in der Region Ihres Triggers verwendet, um den Build auszuführen. Sie müssen den privaten Pool in Ihrer Build-Konfigurationsdatei oder über Build-Argumente angeben.

5. Wählen Sie das Repository aus, in dem Sie den Quellcode gespeichert haben.

   Wenn Sie GitHub (gespiegelt) oder Bitbucket (gespiegelt) als Quell-Repository auswählen, spiegelt Cloud Build Ihr Repository in Cloud Source Repositories und verwendet das gespiegelte Repository für alle Vorgänge.

6. Klicken Sie auf Weiter.

7. Authentifizieren Sie sich mit Ihrem Nutzernamen und Passwort in Ihrem Quell-Repository.

8. Wählen Sie aus der Liste der verfügbaren Repositories ein Repository aus und klicken Sie auf Verbinden.

   Bei externen Repositories wie GitHub und Bitbucket benötigen Sie für das verwendete Google Cloud -Projekt Berechtigungen auf Inhaberebene.

9. Klicken Sie auf Trigger erstellen, um einen Build-Trigger zu erstellen, mit dem Builds für den Quellcode im Repository automatisiert werden, oder klicken Sie auf Fertig.

Build-Trigger erstellen

So erstellen Sie einen Build-Trigger:

Hinweis :Wenn Sie ein eigenes Dienstkonto für Builds angeben, müssen Sie Ihre Build-Logs in einem Cloud Logging-Bucket, in einem von Nutzern erstellten Cloud Storage-Bucket oder in einem von Google Clouderstellten und von Nutzern verwalteten Cloud Storage-Bucket speichern. Sie können Ihre Logs nicht in einem Log-Bucket speichern, das Google Cloudgehört. Weitere Informationen finden Sie unter Build-Logs einrichten.

Console

1. Öffnen Sie in der Google Cloud Console die Seite Trigger.

   Seite "Trigger" aufrufen

2. Wählen Sie in der Symbolleiste der Google Cloud Console Ihr Projekt von Google Cloud aus.

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 Ihren Trigger aus.

     Wenn in der mit Ihrem Trigger verknüpften Build-Konfigurationsdatei ein privater Pool angegeben ist, muss die Region, die Sie für Ihren Trigger auswählen, mit der Region des privaten Pools übereinstimmen.

     Wenn Sie global als Region auswählen, verwendet Cloud Build die in Ihrer Build-Konfigurationsdatei angegebene Region, um Ihren Build auszuführen. Dies kann entweder die Region des privaten Pools sein, wenn Sie einen privaten Pool in Ihrer Build-Konfigurationsdatei angeben, oder der globale Standardpool, wenn Sie keinen privaten Pool angeben.

   • Beschreibung (optional): Geben Sie eine Beschreibung für den Trigger ein.

   • Ereignis: Wählen Sie das Repository-Ereignis aus, um den Trigger aufzurufen.

     • Push zu Zweig: Legen Sie den Trigger so fest, dass ein Build für Commits zu einem bestimmten Zweig gestartet wird.

     • Neues Tag mit Push übertragen: Legen Sie den Trigger so fest, dass ein Build für Commits gestartet wird, die ein bestimmtes Tag enthalten.

     • Pull-Anfrage: Legen Sie den Trigger so fest, dass ein Build für Commits zu einer Pull-Anfrage gestartet wird.

       Hinweis: Unabhängig davon, ob Builds auf Zweig-Commits oder Tag-Commits basieren, werden sie nur bei einem Push zum Remote-Ursprung ausgelöst und nicht bei lokalen Änderungen, Vorabsendungen oder Pull-Anfragen.

   • Quelle: Wählen Sie 1. Generation oder 2. Generation als Quelle aus. Sie können nur Repositories von GitHub und GitHub Enterprise verbinden, wenn Sie 2. Generation als Quelle auswählen. Weitere Informationen finden Sie unter Cloud Build-Repositories.

     Hinweis :Die Region Ihres Repositorys muss mit der Region Ihres Triggers übereinstimmen. Wenn Ihre Quelle ein Cloud Source Repository ist, ist Ihr Repository nicht mit einer bestimmten Region, sondern mit Ihrem Projekt verbunden.
     • Repository: Wählen Sie in der Liste der verfügbaren Repositories ein Repository aus. Informationen zum Verbinden eines neuen Repositories finden Sie unter Verbindung zu Quell-Repositories herstellen.
     Hinweis :Wenn Sie Ihr Repository nach der Triggererstellung umbenennen, müssen Sie den Repository-Namen in Ihrem Trigger manuell aktualisieren. Cloud Build leitet Build-Anfragen von Ihrem Trigger nicht um, wenn ein Repository-Name aktualisiert wird.

     • Zweig oder Tag: Geben Sie einen regulären Ausdruck mit dem abzugleichenden Zweig- oder Tag-Wert an. Schrägstriche (/) können nicht in Tags verwendet werden. Weitere Informationen zur zulässigen Syntax für reguläre Ausdrücke finden Sie unter RE2-Syntax.

       Wenn Ihr Build ausgeführt wird, kopiert Cloud Build den Inhalt Ihres Repositorys in /workspace, das Standardarbeitsverzeichnis für Cloud Build. Weitere Informationen zu Arbeitsverzeichnissen finden Sie auf der Seite Build-Konfiguration – Übersicht.

       Wenn Sie nur Builds aus bestimmten Quellen zulassen möchten, legen Sie eine Organisationsrichtlinie für zulässige Integrationen (constraints/cloudbuild.allowedIntegrations) fest, um die Interaktion mit der in Ihrem Trigger definierten Quelle zu verweigern. Die Organisationsrichtlinie überschreibt den Trigger und Ihr Build wird nicht ausgeführt. Weitere Informationen finden Sie unter Builds auf Grundlage von Organisationsrichtlinien blockieren.

     Hinweis :Sie erhalten Vorschläge basierend auf den in Ihrem Repository vorhandenen Branches oder Tags. Wenn Sie ein Repository der 2. Generation mit mehr als 500 Branches oder Tags verwenden, fehlen einige davon in der Liste. Sie können einen regulären Ausdruck manuell angeben.

   • Enthaltene Dateien (optional): Änderungen, die mindestens eine dieser Dateien betreffen, lösen einen Build aus. Sie können Glob-Strings verwenden, um mehrere Dateien mit Platzhalterzeichen anzugeben. Zulässige Platzhalterzeichen werden von Go Match, ** und Alternation unterstützt.

     Hinweis:** ist eine rekursive Version von *, die alle Dateien und Verzeichnisse im ausgewählten Verzeichnis und dessen Unterverzeichnissen angibt. So stimmt beispielsweise das Muster src/* mit src/code.py überein, ignoriert jedoch src/sub/code.py. Das Muster src/** hingegen stimmt mit beiden überein.

   • Ignorierte Dateien (optional): Änderungen, die nur ignorierte Dateien betreffen, lösen keinen Build aus. Sie können Glob-Strings verwenden, um mehrere Dateien mit Platzhalterzeichen anzugeben. Zulässige Platzhalterzeichen werden von Go Match, ** und Alternation unterstützt.

     Hinweis :Glob-Strings lassen keine Ersetzungsvariablen in eingeschlossenen und ignorierten Dateien zu.

     Wenn Sie eine Datei sowohl in Enthaltene Dateien als auch in Ignorierte Dateien angeben, wird bei Änderungen an dieser Datei kein Build ausgelöst. Beispiel: Sie geben **/README.md in Ignorierte Dateien an, um README.md in allen Verzeichnissen zu ignorieren. Außerdem legen Sie src/* unter Enthaltene Dateien fest, damit bei Änderungen an einer beliebigen Datei im Ordner src/ ein Build ausgelöst wird. Wenn Sie jetzt eine Änderung an src/README.md vornehmen, wird kein Build in Cloud Build gestartet. Jedes Mal, wenn Sie per Push eine Änderung an Ihrer Quelle vornehmen, durchsucht Cloud Build Ihre geänderten Dateien nach enthaltenen und ignorierten Dateien, um zu bestimmen, ob ein Build ausgelöst werden soll:

     • Wenn Sie per Push eine Änderung an Ihrem Repository in einem vorhandenen Branch vornehmen, prüft Cloud Build die Dateien, die zwischen dem soeben übertragenen Commit und dem Commit, auf das der Branch zuvor verwiesen hat, geändert wurden.
     • Wenn Ihr Repository ein Cloud Source Repository ist und Sie per Push eine Änderung an einem neu erstellten Zweig vornehmen, behandelt Cloud Build alle Dateien im Repository als geänderte Dateien.
     • Wenn Sie einen Zweig löschen, startet Cloud Build keinen Build.
   Hinweis :Enthaltene Dateien und Ignorierte Dateien können nur angegeben werden, wenn Sie als Ereignis die Option Push zu Zweig oder Push-Tag ausgewählt haben.

   • 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 Ihrem Remote-Repository befindet, geben Sie den Speicherort Ihrer Build-Konfigurationsdatei, des Dockerfile-Verzeichnisses oder des Buildpacks-Verzeichnisses an. Wenn Ihr Build-Konfigurationstyp ein 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 derGoogle Cloud console 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.

   • Privaten Pool verwenden: Dieses Feld wird angezeigt, wenn Sie Dockerfile als Konfigurationsoption ausgewählt haben. Klicken Sie dieses Kästchen an, wenn Sie den Build in einem privaten Pool ausführen.

   • Privater Pool: Wenn Sie Privaten Pool verwenden ausgewählt haben, geben Sie den Ressourcennamen des privaten Pools im Format projects/WORKERPOOL_PROJECT_ID/locations/REGION/workerPools/WORKERPOOL_ID an.

   • Substitutionsvariablen (optional): Wenn Sie die Cloud Build-Konfigurationsdatei als Build-Konfigurationsoption ausgewählt haben, können Sie triggerspezifische Substitutionsvariablen mithilfe dieses Felds definieren. Beispiel: Sie erstellen mehrere Trigger, bei denen jeder Trigger Ihre Anwendung für eine bestimmte Umgebung bereitstellt. Sie können angeben, dass Ihre Anwendung in einer Umgebung in Ihrer Build-Konfigurationsdatei bereitgestellt wird und dieses Feld verwenden, um Substitutionsvariablen zu definieren, die festlegen, in welcher Umgebung dieser Trigger bereitgestellt werden soll. Informationen zum Angeben von Substitutionswerten in Build-Konfigurationsdateien finden Sie unter Variablenwerte ersetzen.

   • Genehmigung (optional): Klicken Sie das Kästchen an, um vor der Ausführung des Builds die Genehmigung anzufordern.

   • Dienstkonto: Wählen Sie das Dienstkonto aus, das beim Aufrufen des Triggers verwendet werden soll. Für Builds, die durch Trigger ausgeführt werden, wird nur das in Ihrem Trigger angegebene Dienstkonto verwendet. Wenn Sie in Ihrer Build-Konfiguration ein Dienstkonto angegeben haben, wird es bei der Ausführung des Builds ignoriert, wenn Sie Trigger verwenden.

5. Klicken Sie auf Erstellen, um den Build-Trigger zu speichern.

gcloud

So erstellen Sie einen Trigger, wenn sich der Quellcode in Cloud Source Repositories befindet:

    gcloud builds triggers create cloud-source-repositories \
    --repo=REPO_NAME \
    --branch-pattern=BRANCH_PATTERN \ # or --tag-pattern=TAG_PATTERN
    --build-config=BUILD_CONFIG_FILE \
    --service-account=SERVICE_ACCOUNT \
    --require-approval

Dabei gilt:

• REPO_NAME ist der Name Ihres Repositorys.
• BRANCH_PATTERN ist der Zweigname in Ihrem Repository, für den der Build aufgerufen werden soll.
• TAG_PATTERN ist der Tag-Name in Ihrem Repository, mit dem der Build aufgerufen werden soll.
• BUILD_CONFIG_FILE ist der Pfad zu Ihrer Build-Konfigurationsdatei.
• SERVICE_ACCOUNT ist das Dienstkonto, das für Trigger- und Build-Vorgänge verwendet werden soll.

Hinweis: Nur das im Befehl gcloud builds triggers create angegebene Dienstkonto wird für Builds verwendet, die mit Triggern aufgerufen werden. Build-Trigger ignorieren das in der Build-Konfigurationsdatei angegebene Dienstkonto.

• Optional: Wenn Sie den Trigger so konfigurieren möchten, dass eine Genehmigung erforderlich ist, legen Sie das Flag --require-approval fest.

Eine vollständige Liste der Flags finden Sie in der gcloud-Referenz zum Erstellen von Triggern für Cloud Source Repositories.

So erstellen Sie einen Trigger, wenn sich Ihr Quellcode in GitHub befindet:

    gcloud builds triggers create github \
    --name=TRIGGER_NAME \
    --region=REGION \
    --repo-name=REPO_NAME \
    --repo-owner=REPO_OWNER \
    --branch-pattern=BRANCH_PATTERN \ # or --tag-pattern=TAG_PATTERN
    --build-config=BUILD_CONFIG_FILE \
    --service-account=SERVICE_ACCOUNT \
    --require-approval
    --include-logs-with-status

Wobei:

• REGION ist die Region für Ihren Trigger.
• REPO_NAME ist der Name Ihres Repositorys.
• REPO_OWNER ist der Nutzername des Repository-Inhabers.
• BRANCH_PATTERN ist der Zweigname in Ihrem Repository, für den der Build aufgerufen werden soll.
• TAG_PATTERN ist der Tag-Name in Ihrem Repository, mit dem der Build aufgerufen werden soll.
• BUILD_CONFIG_FILE ist der Pfad zu Ihrer Build-Konfigurationsdatei.
• SERVICE_ACCOUNT ist das Dienstkonto, das für Trigger- und Build-Vorgänge verwendet werden soll.
• Optional: --require-approval ist das Flag, das Sie einfügen können, um für Ihren Trigger eine Genehmigung zu erzwingen.
• Optional: --include-logs-with-status ist ein Flag, das Sie angeben können, um Build-Logs für Ihre Repositorys aufzurufen. Dieses Flag wird für Builds aus GitHub- und GitHub Enterprise-Repositories unterstützt.

Hinweis: Sie können das Flag --include-logs-with-status nur verwenden, wenn Sie einen GitHub- oder GitHub Enterprise-Trigger mit gcloud erstellen. Cloud Build unterstützt das Erstellen von Triggern in der Google Cloud Console

nicht.

Eine vollständige Liste der Flags finden Sie in der gcloud-Referenz zum Erstellen von Triggern für GitHub.

Nachdem Sie den gcloud-Befehl zum Erstellen eines Triggers mit Cloud Source-Repositories oder GitHub ausgeführt haben, sollte eine Ausgabe ähnlich der folgenden angezeigt werden:

  NAME         CREATE_TIME                STATUS
  trigger-001  2019-10-30T20:45:03+00:00

Hinweis :Der Triggername wird automatisch für Sie generiert. Sie können den Namen des Triggers über die Google Cloud Console ändern.

Build-Trigger testen

So wird ein Build-Trigger manuell getestet:

1. Öffnen Sie in der Google Cloud Console die Seite Trigger.

   Zur Seite "Trigger"

2. Wählen Sie in der Symbolleiste der Google Cloud Console Ihr Projekt von Google Cloud aus.

3. Suchen Sie in der Liste nach dem Trigger und klicken Sie auf Ausführen.

Build-Trigger überspringen

In einigen Fällen können Sie eine Änderung am Quellcode vornehmen, aber keinen Build auslösen. Beispielsweise sind Sie wahrscheinlich nicht daran interessiert, einen Build auszulösen, wenn Sie Dokumentations- oder Konfigurationsdateien aktualisieren.

In solchen Fällen können Sie [skip ci] oder [ci skip] in die Commit-Nachricht aufnehmen, damit kein Build aufgerufen wird.

Wenn Sie später einen Build auf diesem Commit ausführen möchten, verwenden Sie auf der Seite Trigger den Button Ausführen.

Repository-Verlauf in einen Build einbeziehen

Wenn Sie Ihre Quelle in einem Git-Repository erstellen möchten, führt Cloud Build einen flachen Klon des Repositorys aus. Das bedeutet, dass nur der einzelne Commit, der den Build gestartet hat, im zu erstellenden Arbeitsbereich ausgecheckt wird. Cloud Build überprüft keine anderen Branches oder Verläufe. Dies geschieht aus Effizienzgründen, damit Builds nicht auf den Abruf des gesamten Repositorys und des Verlaufs warten müssen, nur um einen einzelnen Commit zu erstellen.

Wenn Sie einen größeren Teil Ihres Repository-Verlaufs in den Build einbeziehen möchten, fügen Sie einen Build-Schritt zu Ihrer Build-Konfigurationsdatei hinzu, um den "oberflächlichen" Klon zu umgehen. Beispiel:

steps:
- name: gcr.io/cloud-builders/git
  args: ['fetch', '--unshallow']
...

Hinweis :Wenn sich Ihre Quelle in einem privaten Git-Repository befindet, müssen Sie Ihre Anmeldedaten sicher mit Secret Manager speichern, um auf git-Befehle wie den vorherigen Befehl zuzugreifen, mit dem der Klon Ihres Repositorys „unshallow“ wird. Eine ausführliche Anleitung finden Sie unter Auf private GitHub-Repositories zugreifen.

Weitere Informationen zu git fetch finden Sie in der Git-Referenz. Anleitungen zum Schreiben einer Build-Konfigurationsdatei finden Sie in der Übersicht zur Build-Konfiguration.

Build noch einmal zur Genehmigung einreichen

Wenn Ihr Build abgelehnt wurde, können Sie ihn noch einmal zur Genehmigung einreichen, indem Sie die folgenden Schritte in der Google Cloud -Konsole ausführen:

1. Öffnen Sie in der Google Cloud Console die Seite Cloud Build-Verlauf.

   Zur Seite „Cloud Build-Verlauf“

2. Klicken Sie auf die Build-ID des Builds, den Sie noch einmal zur Genehmigung einreichen möchten.

3. Klicken Sie oben auf der Seite auf Neu erstellen, um den Build noch einmal zur Genehmigung zu senden.

Ihr Build wird gestartet, wenn ein Nutzer mit Berechtigungen Ihren Build genehmigt. Weitere Informationen zu Cloud Build-Genehmigungen finden Sie unter Builds über Genehmigungen sperren.

Build-Trigger aktualisieren

Console

1. Öffnen Sie in der Google Cloud Console die Seite Trigger.

   Zur Seite "Build-Trigger"

2. Wählen Sie in der Symbolleiste der Google Cloud Console Ihr Projekt von Google Cloud aus.

3. Suchen Sie die Zeile mit dem Trigger, den Sie aktualisieren möchten.

4. Klicken Sie auf das Menü (vertikale Auslassungspunkte), das sich am rechten Ende der Zeile befindet.

5. Wählen Sie Bearbeiten aus.

Hinweis :Sie können alle Felder, die mit Ihrem Trigger verknüpft sind, über die Google Cloud -Konsole aktualisieren. Das Anzeigen von Build-Logs ist jedoch nicht möglich. gcloud

gcloud

So aktualisieren Sie einen Trigger:

1. Exportieren Sie den Trigger, den Sie aktualisieren möchten:

    gcloud beta builds triggers export TRIGGER_NAME --destination=EXPORT_PATH
   

   Wobei:

   • TRIGGER_NAME ist der Name des Triggers.
   • EXPORT_PATH ist der Pfad, in den Sie den Trigger exportieren möchten. Sie können beispielsweise examples/trigger.yaml als Pfad angeben. Der Dateiname für den Trigger muss die YAML-Erweiterung haben.

2. Öffnen Sie die Datei mit dem exportierten Trigger.

   Ihre Datei sieht in etwa so aus:

    createTime: '2022-05-26T21:56:11.830784153Z'
    filename: cloudbuild.yaml
    github:
      name: cloud-build-example
      owner: main
      push:
        branch: master
    id: 86201062-3b14-4b6a-a2fb-4ee924e8b1dd
    # remove field name and value to not show build logs
    includeBuildLogs: INCLUDE_BUILD_LOGS_WITH_STATUS
    name: trigger-001
   

3. Bearbeiten Sie die Datei manuell, um den Trigger zu aktualisieren.

   Hier finden Sie die Felder, die Sie Ihrem Trigger hinzufügen oder daraus entfernen können.

4. Speichern Sie die Datei.

5. Importieren Sie den Trigger:

    gcloud builds triggers import --source=IMPORT_PATH
   

   Wobei:

   • IMPORT_PATH ist der Pfad des Triggers, den Sie importieren möchten.

Ihr Build-Trigger wurde aktualisiert.

Build-Trigger deaktivieren

Console

1. Öffnen Sie in der Google Cloud Console die Seite Trigger.

   Zur Seite "Build-Trigger"

2. Wählen Sie in der Symbolleiste der Google Cloud Console Ihr Projekt von Google Cloud aus.

3. Suchen Sie die Zeile mit dem Trigger, den Sie deaktivieren möchten.

4. Klicken Sie auf das Menü (vertikale Auslassungspunkte), das sich am rechten Ende der Zeile befindet.

5. Wählen Sie Disable (Deaktivieren) aus.

gcloud

So deaktivieren Sie einen Trigger:

1. Exportieren Sie den Trigger, den Sie deaktivieren möchten:

    gcloud beta builds triggers export TRIGGER_NAME --destination=EXPORT_PATH
   

   Wobei:

   • TRIGGER_NAME ist der Name des Triggers.
   • EXPORT_PATH ist der Pfad, in den Sie den Trigger exportieren möchten. Sie können beispielsweise examples/trigger.yaml als Pfad angeben. Der Dateiname für den Trigger muss die YAML-Erweiterung haben.

2. Öffnen Sie die Datei mit dem exportierten Trigger.

   Ihre Datei sieht in etwa so aus:

    createTime: '2020-02-21T20:02:50.215599013Z'
    description: Push to any branch
    filename: cloudbuild.yaml
    github:
      name: example-repo-name
      owner: example-owner
      push:
        branch: .*
    id: example-id
    name: Push-to-any-branch
    tags:
    - github-default-push-trigger
   

3. Fügen Sie das Feld disabled am Ende der Datei hinzu und legen Sie den Wert auf True fest.

    disabled: True
   

4. Speichern Sie die Datei.

5. Importieren Sie den Trigger:

    gcloud builds triggers import --source=IMPORT_PATH
   

   Wobei:

   • IMPORT_PATH ist der Pfad des Triggers, den Sie importieren möchten.

Der Build-Trigger ist jetzt deaktiviert.

Hinweis :Das Deaktivieren eines Triggers mit gcloud-Befehlen funktioniert möglicherweise nicht, wenn Ihrem Trigger keine Build-Konfigurationsdatei zugeordnet ist.

Durch das Deaktivieren eines Triggers wird der Trigger nicht gelöscht. Informationen zum Löschen eines Triggers finden Sie unter Build-Trigger löschen. Ein Trigger kann wieder aktiviert werden, indem Sie den Status in Aktiviert ändern.

Build-Trigger löschen

Console

1. Öffnen Sie in der Google Cloud Console die Seite Trigger.

   Zur Seite "Build-Trigger"

2. Wählen Sie in der Symbolleiste der Google Cloud Console Ihr Projekt von Google Cloud aus.

3. Suchen Sie die Zeile mit dem Trigger, den Sie löschen möchten.

4. Klicken Sie auf das Menü (vertikale Auslassungspunkte), das sich am rechten Ende der Zeile befindet.

5. Wählen Sie Löschen aus.

gcloud

Führen Sie den folgenden Befehl aus, um einen Trigger zu löschen:

  gcloud builds triggers delete TRIGGER_NAME

Dabei gilt:

• TRIGGER_NAME ist der Name des Triggers.

Eine vollständige Liste der Flags finden Sie in der Referenz zu gcloud.

Sicherheitsauswirkungen von Build-Triggern

Das für einen Build-Trigger konfigurierte Dienstkonto kann Nutzern, die einen Build mit Triggern aufrufen, erhöhte Berechtigungen für die Build-Laufzeit gewähren. Dies gilt sowohl für Ihr Cloud Build-Standarddienstkonto als auch für benutzerdefinierte Dienstkonten. Beachten Sie bei der Verwendung von Build-Triggern die folgenden Sicherheitsaspekte:

• Ein Nutzer ohne Zugriff auf Ihr Cloud-Projekt, aber mit Schreibzugriff auf das Repository, das mit Build-Triggern im Projekt verknüpft ist, verfügt über Berechtigungen zum Ändern des erstellten Codes.
• Wenn Sie GitHub-Pull-Anfrage-Trigger verwenden, kann jeder Nutzer mit Lesezugriff auf das Repository eine Pull-Anfrage senden. Diese kann einen Build ausführen, der Änderungen am Code in der Pull-Anfrage enthält. Informationen zum Deaktivieren dieses Verhaltens für GitHub-Pull-Anfrage-Trigger finden Sie unter GitHub-Trigger erstellen.

Wir empfehlen, ein Dienstkonto mit nur den erforderlichen Rollen für Ihren Trigger zu erstellen. Weitere Informationen finden Sie unter Benutzerdefinierte Dienstkonten konfigurieren. Weitere Informationen zum Standard-Cloud Build-Dienstkonto und den zugehörigen Berechtigungen finden Sie unter Cloud Build-Dienstkonto.

Nächste Schritte

• Builds manuell starten oder Bereitstellungen einrichten, die einen manuellen Aufruf erfordern, indem Sie Code in Quell-Repositories manuell erstellen
• GitHub-Trigger erstellen
• Builds als Reaktion auf Pub/Sub-Ereignisse automatisieren
• Builds als Reaktion auf Webhook-Ereignisse automatisieren
• Build-Ergebnisse für Build-Trigger ansehen
• Blau/Grün-Bereitstellungen in Compute Engine durchführen
• Build-Fehler beheben