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.

Hinweis

  • 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. Gehen Sie so vor, um eine Verbindung zu GitHub und Bitbucket herzustellen:

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

    Öffnen Sie die Seite "Trigger"

  2. Wählen Sie Ihr Projekt aus und klicken Sie auf Öffnen.

  3. Klicken Sie auf Repository verbinden.

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

  5. Klicken Sie auf Weiter.

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

  7. Wählen Sie aus der Liste der verfügbaren Repositories das gewünschte Repository aus und klicken Sie auf Repository verbinden.

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

  8. Klicken Sie auf Trigger hinzufügen, 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.

    Zur Seite "Trigger"

  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.

    • 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 (nur GitHub-App): Legen Sie den Trigger so fest, dass ein Build für Commits zu einer Pull-Anfrage gestartet wird. Diese Funktion ist nur verfügbar, wenn Sie einen GitHub App-Trigger erstellen. Informationen zum Erstellen eines GitHub App-Triggers finden Sie unter GitHub App-Trigger erstellen.

    • Quelle: Wählen Sie das Repository und den entsprechenden Zweig oder das entsprechende Tag aus, um es auf Ereignisse zu prüfen.

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

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

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

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

      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 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.
    • Build-Konfiguration: Wählen Sie die Build-Konfigurationsdatei aus, die sich im Remote-Repository befindet, um sie für Ihren Build zu verwenden.

      • Damit Sie ein Dockerfile für die Build-Konfiguration verwenden können, müssen Sie das Dockerfile-Verzeichnis festlegen und einen Namen für das resultierende Image vergeben. Optional können Sie auch eine Zeitüberschreitung für Ihren Build angeben. Wenn Sie Dockerfile und den Image-Namen angegeben haben, sehen Sie eine Vorschau des Befehls docker build, den Ihr Build ausführen wird.

      • Zur Verwendung einer Build-Konfigurationsdatei für Ihre Build-Konfiguration müssen Sie den Speicherort einer Build-Konfigurationsdatei angeben.

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

  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 beta builds triggers create cloud-source-repositories \
    --repo=[REPO_NAME] \
    --branch-pattern=".*" \
    --build-config=[BUILD_CONFIG_FILE] \

Dabei gilt:

  • --repo ist der Name Ihres Repositorys.
  • --branch-pattern ist Ihr Triggertyp, der als String angegeben ist. Im obigen Beispiel geben wir ".*", an. Das weist darauf hin, dass ein Build ausgelöst wird, wenn Änderungen an einen beliebigen Zweig im Repository gesendet werden. Sie können auch --tag-pattern verwenden, um anzugeben, dass Builds nur ausgelöst werden, wenn sie an bestimmte Tags gesendet werden.
  • --build-config ist der Pfad zu Ihrer Build-Konfigurationsdatei.

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 beta builds triggers create github \
    --repo-name=[REPO_NAME] \
    --repo-owner=[REPO_OWNER] \
    --branch-pattern=".*" \
    --build-config=[BUILD_CONFIG_FILE] \

Dabei gilt:

  • --repo-name ist der Name Ihres Repositorys.
  • --repo-owner ist der Name des Eigentümers des Repositorys.
  • --branch-pattern ist Ihr Triggertyp, der als String angegeben ist. Im obigen Beispiel geben wir ".*", an. Das weist darauf hin, dass ein Build ausgelöst wird, wenn Änderungen an einen beliebigen Zweig im Repository gesendet werden. Sie können auch --tag-pattern verwenden, um anzugeben, dass Builds nur ausgelöst werden, wenn sie an bestimmte Tags oder --pull-request-pattern gesendet werden, um den Basis-Git-Zweig für alle Pull-Anfrage-Ereignisse anzugeben.
  • --build-config ist der Pfad zu Ihrer Build-Konfigurationsdatei.

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

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']
...

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.

Wenn Sie GitHub App-Trigger für Builds verwenden, ruft Cloud Build Ihre Quelle aus einem Cloud Storage-Archiv ab. Daher müssen Sie Ihr Git-Repository zuerst klonen, bevor Sie es abrufen:

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

Dabei ist [REPOSITORY_URL] die URL des zu klonenden Repositorys.

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 beta builds triggers export [NAME] --destination=[PATH]
    

    Wobei:

    • [NAME] ist der Name des Triggers.
    • [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 beta builds triggers import --source=[PATH]
    

    Wobei:

    • [PATH] ist der Dateipfad des Triggers, den Sie importieren möchten.

Der Build-Trigger ist jetzt deaktiviert.

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 beta builds triggers delete [NAME]

Dabei gilt:

  • [NAME] ist der Name des Triggers.

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

Auswirkungen der Sicherheit von Build-Triggern

Build-Trigger verwenden das Cloud Build-Konto, um Builds auszuführen. Dies könnte Nutzern, die Trigger zum Ausführen eines Builds verwenden, Build-Zeit-Berechtigungen erteilen. Beachten Sie die folgenden Auswirkungen auf die Sicherheit, wenn Sie Build-Trigger verwenden:

  • 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-App-Trigger erstellen.

Weitere Informationen zum Cloud Build-Dienstkonto und den damit verbundenen Berechtigungen finden Sie unter Cloud Build-Dienstkonto.

Nächste Schritte