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

  • Enable the Cloud Build API.

    Enable the 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.

    Öffnen Sie die 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 Google 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.

    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.

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

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

      Wenn Sie global als Region auswählen, verwendet die in der Build-Konfigurationsdatei angegebene Region um Ihren Build auszuführen. Dies kann entweder die Region des privater Pool wenn Sie in der Build-Konfigurationsdatei einen privaten Pool 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: Legen Sie den Trigger zum Starten eines Builds fest. zu Commits zu einer Pull-Anfrage.

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

      • 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 die Inhalte Ihres Repositorys in /workspace, die Standardeinstellung, Arbeitsverzeichnis 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 Interaktionen abzulehnen mit der im Trigger definierten Quelle. Die Organisation überschreibt den Trigger und der Build wird nicht ausgeführt. Weitere Informationen finden Sie unter Gate baut auf der Organisationsrichtlinie auf.

    • 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 ein Cloud Source Repository ist und Sie eine Änderung per Push an einen neu erstellten Zweig übertragen, dann Cloud Build behandelt 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 die 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 den Google Cloud Console mit YAML- oder JSON-Syntax 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-Legacy-Dienstkonto verwendet, sofern es für Ihr Projekt verfügbar ist.

  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

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. Ohne dieses Flag wird der Parameter Legacy-Cloud Build-Dienstkonto wenn es für Ihr Projekt verfügbar ist.
  • [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 den 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. Ohne dieses Flag wird der Parameter Legacy-Cloud Build-Dienstkonto wenn es für Ihr Projekt verfügbar ist.
  • [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 Führen Sie dazu folgende Schritte in der Google Cloud Console aus:

  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. Bis Weitere Informationen zu Cloud Build-Genehmigungen finden Sie unter Gate baut auf Genehmigung auf.

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

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

    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.

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

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.

Sicherheitsauswirkungen von Build-Triggern

Das für einen Build-Trigger konfigurierte Dienstkonto kann erhöhte Erstellungszeitberechtigungen für Nutzer, die einen Build mithilfe von Triggern aufrufen. Das gilt sowohl für das Cloud Build-Standarddienstkonto als auch für vom Nutzer angegebene Dienstkonten. Beachten Sie die folgenden Sicherheitshinweise Auswirkungen bei der Verwendung von Build-Triggern:

  • 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 nur mit den erforderlichen für den Trigger festlegen. Weitere Informationen finden Sie unter Benutzerdefinierte Dienstkonten konfigurieren. Weitere Informationen zum Legacy-Dienst von Cloud Build und den zugehörigen Berechtigungen finden Sie unter Cloud Build-Dienst Konto.

Nächste Schritte