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 er Ihren Code bei allen Änderungen am Quell-Repository erstellt, oder nur bei Änderungen, die bestimmte Kriterien erfüllen.

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.

Hinweise

• Cloud Build API aktivieren.

  Aktivieren Sie die API

• Sie benötigen die Rolle Cloud Build Editor (roles/cloudbuild.builds.editor) in Ihrem Projekt, um Trigger zu erstellen.
• Sie benötigen Quellcode in Cloud Source Repositories, GitHub oder Bitbucket.
• Sie benötigen entweder ein Dockerfile oder eine Cloud Build-Konfigurationsdatei.

Verbindung zu Quell-Repositories herstellen

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

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 Ihr Projekt aus und klicken Sie auf Öffnen.

3. 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 zum Ausführen Ihres Builds verwendet. Andernfalls wird ein privater Pool in der Region des Triggers zum Ausführen des Builds verwendet. Sie müssen den privaten Pool in der Build-Konfigurationsdatei oder über Build-Argumente angeben.

4. Klicken Sie auf Repository verbinden.

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 das gewünschte Repository aus und klicken Sie auf Verbinden.

   Für externe Repositories wie GitHub und Bitbucket benötigen Sie Berechtigungen auf Inhaberebene für das Google Cloud-Projekt, mit dem Sie arbeiten.

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

Build-Trigger erstellen

Console

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

   Seite "Trigger" aufrufen

2. Wählen Sie oben auf der Seite im Drop-down-Menü zur Projektauswahl Ihr Projekt aus.

3. Klicken Sie auf Öffnen.

4. Klicken Sie auf Trigger erstellen.

5. 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 die mit dem Trigger verknüpfte Build-Konfigurationsdatei einen privaten Pool angibt, muss die Region, die Sie für den Trigger auswählen, mit der Region des privaten Pools übereinstimmen.

     Wenn Sie global als Region auswählen, verwendet Cloud Build die in der Build-Konfigurationsdatei angegebene Region, um Ihren Build auszuführen. Dies kann entweder die Region des privaten Pools sein, wenn Sie in der Build-Konfigurationsdatei einen privaten Pool 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, das den Trigger auslösen soll.

     • 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: Builds werden nur bei Push-Übertragungen an den Remote-Ursprung aufgerufen, unabhängig davon, ob sie auf Zweig- oder Tag-Commits basieren. Bei lokalen Änderungen, Vorabsendungen oder Pull-Anfragen werden sie nicht aufgerufen.

   • 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 die Quelle ein Cloud Source Repository ist, ist es nicht mit einer bestimmten Region, sondern mit Ihrem Projekt verbunden.
     • Repository: Wählen Sie aus der Liste der verfügbaren Repositories das gewünschte Repository aus. Informationen zum Verbinden eines neuen Repositories finden Sie unter Verbindung zu Quell-Repositories herstellen.
     Hinweis: Wenn Sie das Repository nach dem Erstellen des Triggers umbenennen, müssen Sie den Repository-Namen in Ihrem Trigger manuell aktualisieren. Derzeit leitet Cloud Build Build-Anfragen von Ihrem Trigger nicht automatisch weiter, 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.

       Bei der Ausführung des Builds 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 im Trigger definierten Quelle abzulehnen. Die Organisationsrichtlinie überschreibt den Trigger und der Build wird nicht ausgeführt. Weitere Informationen finden Sie im Abschnitt Gate-Builds auf Organisationsrichtlinie für Ihr Projekt.

   • 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 sich nur auf die ignorierten Dateien beziehen, 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 erlauben keine Substitutionsvariablen in enthaltenen und ignorierten Dateien.

     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, löst Cloud Build keinen Build aus. 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 eine Änderung in einen neu erstellten Zweig übertragen, 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 Push an Zweig oder Neues Tag senden als Ereignis auswählen.

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

         Hinweis: Die Unterstützung der Inline-Build-Konfiguration ist für Dockerfile oder Buildpacks nicht verfügbar.

   • 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. Wenn Sie kein Dienstkonto auswählen, wird das Cloud Build-Standarddienstkonto verwendet.

     Hinweis: Für Builds, die durch Trigger ausgeführt werden, wird nur das Dienstkonto verwendet, das in Ihrem Trigger angegeben ist. Wenn Sie in der Build-Konfiguration ein Dienstkonto angegeben haben, wird es bei der Verwendung von Triggern während der Build-Ausführung ignoriert.

6. 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

Wobei:

• 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, in dem der Build ausgelöst werden soll.

• BUILD_CONFIG_FILE ist der Pfad zu Ihrer Build-Konfigurationsdatei.

• SERVICE_ACCOUNT ist die mit Ihrem Dienstkonto verknüpfte E-Mail-Adresse. Wenn Sie dieses Flag nicht angeben, wird das Standard-Cloud Build-Dienstkonto verwendet.

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] --require-approval ist das Flag, das konfiguriert werden soll, um den Trigger so zu konfigurieren, dass er erforderlich ist.

Eine vollständige Liste der Flags finden Sie unter gcloud-Referenz zur Erstellung von Triggern für Cloud Source Repositories.

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

    gcloud builds triggers create github \
    --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, in dem der Build ausgelöst werden soll.
• BUILD_CONFIG_FILE ist der Pfad zu Ihrer Build-Konfigurationsdatei.
• SERVICE_ACCOUNT ist die mit Ihrem Dienstkonto verknüpfte E-Mail-Adresse. Wenn Sie dieses Flag nicht angeben, wird das Standard-Cloud Build-Dienstkonto verwendet.
• [Optional] --require-approval ist das Flag, das konfiguriert werden soll, um den Trigger so zu konfigurieren, dass er erforderlich ist.
• [Optional] --include-logs-with-status ist ein Flag, das Sie zum Anzeigen von Build-Logs für Ihre Repositories angeben können. Dieses Flag wird für Builds von 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 derzeit nicht die Funktion zum Erstellen eines Triggers mit der Google Cloud Console.

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 erstellt. 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. Suchen Sie den Trigger in der Liste und klicken Sie auf Trigger 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.

Wenn Sie in solchen Fällen [skip ci] oder [ci skip] in die Commit-Nachricht aufnehmen, wird kein Build ausgelöst.

Wenn Sie später einen Build auf diesem Commit ausführen möchten, verwenden Sie auf der Seite Trigger die Schaltfläche Trigger ausführen.

Repository-Verlauf in einen Build aufnehmen

Cloud Build führt einen "oberflächlichen" Klon des Repositorys aus, um die Build-Quelle in einem Git Repository zu erstellen. 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 dem obigen Befehl zuzugreifen, um den Klon des Repositorys "aufzuheben". 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 für Genehmigung noch einmal senden

Wenn Ihr Build abgelehnt wurde, können Sie ihn noch einmal zur Genehmigung einreichen. Gehen Sie dazu in der Google Cloud Console so vor:

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 Gate-Builds bei Genehmigung.

Build-Trigger aktualisieren

Console

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

   Zur Seite "Build-Trigger"

2. Wählen Sie oben auf der Seite im Drop-down-Menü zur Projektauswahl Ihr Projekt aus.

3. Klicken Sie auf Öffnen.

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

5. Klicken Sie auf das Menü (vertikale Ellipsen) am rechten Ende der Zeile.

6. Wählen Sie Bearbeiten aus.

Hinweis: Sie können alle mit dem Trigger verknüpften Felder über die Google Cloud Console aktualisieren, außer dass Build-Logs angezeigt werden. In der Anleitung zu gcloud erfahren Sie, wie Sie einen Build-Trigger aktualisieren, um Build-Logs für GitHub- oder GitHub Enterprise-Trigger ein- oder auszublenden.

gcloud

So aktualisieren Sie einen Trigger:

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

    gcloud builds triggers export TRIGGER_NAME --destination=EXPORT_PATH
   

   Wobei:

   • TRIGGER_NAME ist der Name des Triggers.
   • EXPORT_PATH ist der Dateipfad, in den Sie den Trigger exportieren möchten. Sie können Ihren Dateipfad beispielsweise als examples/trigger.yaml angeben. Beachten Sie, dass der Dateiname des Triggers die Erweiterung .yaml haben sollte.

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.

   Informationen zu Feldern, die Sie dem Trigger hinzufügen oder daraus entfernen können, finden Sie unter Trigger-Ressource.

4. Speichern Sie die Datei.

5. Importieren Sie den Trigger:

    gcloud builds triggers import --source=IMPORT_PATH
   

   Wobei:

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

Der Build-Trigger ist jetzt aktualisiert.

Build-Trigger deaktivieren

Console

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

   Zur Seite "Build-Trigger"

2. Wählen Sie oben auf der Seite im Drop-down-Menü zur Projektauswahl Ihr Projekt aus.

3. Klicken Sie auf Öffnen.

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

5. Klicken Sie auf das Menü (vertikale Ellipsen) am rechten Ende der Zeile.

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

gcloud

So deaktivieren Sie einen Trigger:

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

    gcloud builds triggers export TRIGGER_NAME --destination=EXPORT_PATH
   

   Wobei:

   • TRIGGER_NAME ist der Name des Triggers.
   • EXPORT_PATH ist der Dateipfad, in den Sie den Trigger exportieren möchten. Sie können Ihren Dateipfad beispielsweise als examples/trigger.yaml angeben. Beachten Sie, dass der Dateiname des Triggers die Erweiterung .yaml haben sollte.

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 Dateipfad des Triggers, den Sie importieren möchten.

Der Build-Trigger ist jetzt deaktiviert.

Hinweis: Das Deaktivieren eines Triggers mithilfe von gcloud-Befehlen funktioniert möglicherweise nicht, wenn dem 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 oben auf der Seite im Drop-down-Menü zur Projektauswahl Ihr Projekt aus.

3. Klicken Sie auf Öffnen.

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

5. Klicken Sie auf das Menü (vertikale Ellipsen) am rechten Ende der Zeile.

6. 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

Wobei:

• TRIGGER_NAME ist der Name des Triggers.

Eine vollständige Liste der Flags finden Sie unter gcloud-Referenz zum Löschen von Triggern.

Sicherheitsauswirkungen von Build-Triggern

Hinweis: Um den Standardsicherheitsstatus Ihrer Projekte zu verbessern, führt Cloud Build Änderungen ein, die die Auswahl eines Dienstkontos erfordern, wenn Sie einen Trigger in neuen Projekten erstellen. Weitere Informationen finden Sie unter Änderung des Cloud Build-Dienstkontos.

Standardmäßig verwenden Build-Trigger das Cloud Build-Dienstkonto, um Builds auszuführen. Dadurch können Nutzern, die Build-Trigger verwenden, Berechtigungen zur Erstellungszeit zur Verfügung gestellt werden. 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.

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

Nächste Schritte

• Builds manuell starten oder Bereitstellungen einrichten, die manuell aufgerufen werden müssen, indem Sie manuell Code in Quell-Repositories 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 aufrufen
• Blau/Grün-Bereitstellungen in Compute Engine durchführen
• Build-Fehler beheben