Build-Trigger erstellen und verwalten

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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

  • Cloud Build API aktivieren.

    Aktivieren Sie die API

  • Sie benötigen die Rolle Cloud Build-Bearbeiter (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.

  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.

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

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

      Wenn die mit dem Trigger verknüpfte Build-Konfigurationsdatei einen privaten Pool angibt, muss die für den Trigger ausgewählte Region mit der Region des privaten Pools übereinstimmen.

      Wenn Sie global als Region auswählen, verwendet Cloud Build die Region, die in der Build-Konfigurationsdatei angegeben ist, um den Build auszuführen. Dies kann entweder die Region des privaten Pools sein, wenn Sie einen privaten Pool in Ihrer Build-Konfigurationsdatei angeben, oder den globalen 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 (Cloud Source Repositories wird nicht unterstützt): 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-Trigger erstellen. Informationen zum Erstellen eines GitHub-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. 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 nach /workspace, dem 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 zugelassene Integrationen (constraints/cloudbuild.allowedIntegrations) fest, um die Interaktion mit der im Trigger definierten Quelle abzulehnen. Die Organisationsrichtlinie überschreibt den Trigger und Ihr Build wird nicht ausgeführt. Weitere Informationen finden Sie unter 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.

    • 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 Ihr Repository Cloud Source Repository ist und Sie 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.
    • Konfiguration: Wählen Sie die Build-Konfigurationsdatei aus, die sich in Ihrem Remote-Repository befindet, oder erstellen Sie eine Inline-Build-Konfigurationsdatei für den Build.

      • Typ: Wählen Sie den Konfigurationstyp aus, der für Ihren Build verwendet werden soll.
        • Cloud Build-Konfigurationsdatei (YAML oder JSON): Verwenden Sie eine Build-Konfigurationsdatei für Ihre Konfiguration.
        • Dockerfile: Verwenden Sie für Ihre Konfiguration eine Dockerfile.
        • Buildpacks: Verwenden Sie Buildpacks für Ihre Konfiguration.
      • Speicherort: Geben Sie den Speicherort für Ihre Konfiguration an.

        • Repository: Wenn sich Ihre Konfigurationsdatei in Ihrem Remote-Repository befindet, geben Sie den Speicherort Ihrer Build-Konfigurationsdatei, das Verzeichnis der Dockerfile oder das Verzeichnis der Buildpacks an. Wenn Ihr Build-Konfigurationstyp eine Dockerfile oder ein Buildpack ist, müssen Sie einen Namen für das resultierende Image und optional ein Zeitlimit für den Build angeben. Wenn Sie den Image-Namen der Dockerfile oder des Buildpacks angegeben haben, sehen Sie eine Vorschau des Befehls docker build oder pack, den Ihr Build ausführen wird.
        • Buildpack-Umgebungsvariablen (Optional): Wenn Sie buildpacks als Konfigurationstyp ausgewählt haben, klicken Sie auf Pack-Umgebungsvariable hinzufügen, um Ihre Buildpack-Umgebungsvariablen und -werte anzugeben. Weitere Informationen zu Buildpack-Umgebungsvariablen finden Sie unter Umgebungsvariablen.
        • Inline: Wenn Sie die Cloud Build-Konfigurationsdatei (YAML oder JSON) als Konfigurationsoption ausgewählt haben, können Sie die Build-Konfiguration inline angeben. Klicken Sie auf Editor öffnen, um die Build-Konfigurationsdatei in der Google Cloud Console mit YAML- oder JSON-Syntax zu schreiben. Klicken Sie auf Fertig, um die Build-Konfiguration zu speichern.

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

  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=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, 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.

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 \
    --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

Dabei gilt:

  • 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 angeben können, um Build-Logs für Ihre Repositories anzuzeigen. Dieses Flag wird für Builds aus GitHub- und GitHub Enterprise-Repositories unterstützt.

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.

Build für Genehmigung noch einmal senden

Wenn Ihr Build abgelehnt wurde, können Sie ihn noch einmal zur Genehmigung einreichen, indem Sie die folgenden Schritte in der Google Cloud Console 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 Gate-Builds nach 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.

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
    

    Dabei gilt:

    • 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 Ihrem Trigger hinzufügen oder daraus entfernen können, finden Sie unter Trigger-Ressource.

  4. Speichern Sie die Datei.

  5. Importieren Sie den Trigger:

     gcloud beta builds triggers import --source=IMPORT_PATH
    

    Dabei gilt:

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

Der 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 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 TRIGGER_NAME --destination=EXPORT_PATH
    

    Dabei gilt:

    • 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 beta builds triggers import --source=IMPORT_PATH
    

    Dabei gilt:

    • IMPORT_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 TRIGGER_NAME

Dabei gilt:

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

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

Weitere Informationen