Triggerdatei erstellen

Auf dieser Seite werden die Schritte zum Erstellen einer YAML-Datei für Trigger in Secure Source Manager beschrieben. Mit einer Triggerdatei können Sie Builds basierend auf Push- und Pull-Request-Ereignissen in einem Secure Source Manager-Repository automatisieren.

Informationen zu den Feldern, die Sie in einer Triggerdatei verwenden können, finden Sie unter Triggers file schema (Schemadatei für Trigger).

Hinweis

  1. Erstellen Sie eine Secure Source Manager-Instanz.
  2. Erstellen Sie ein Secure Source Manager-Repository.
  3. Lesen Sie das Triggers file schema (Schemadatei für Trigger), um Informationen zu den Feldern zu erhalten, die Sie in einer Triggerdatei verwenden können.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen einer Triggerdatei benötigen:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Cloud Build-Konfigurationsdatei erstellen

Für Secure Source Manager-Triggerdateien müssen Sie für jeden Trigger eine Build-Konfigurationsdatei angeben.

Eine Build-Konfigurationsdatei enthält eine Anleitung, die Cloud Build zur Ausführung von Aufgaben gemäß Ihren Spezifikationen verwendet. Zum Beispiel kann Ihre Build-Konfigurationsdatei Anweisungen zum Erstellen, Packen und Hochladen von Docker-Images enthalten.

Erstellen Sie Ihre Build-Konfigurationsdateien in den Zweigen, aus denen Sie erstellen möchten. Folgen Sie der Anleitung unter Build-Konfigurationsdatei erstellen, um Ihre Build-Konfigurationsdateien zu erstellen.

Triggerdatei erstellen

Die Konfigurationsdatei für Trigger muss im Standardzweig Ihres Repositorys erstellt werden.

So erstellen Sie eine Konfigurationsdatei für Trigger:

  1. Wechseln Sie in Ihrem lokalen Repository oder in der Secure Source Manager-Weboberfläche zum Standardzweig.

  2. Erstellen Sie eine Datei mit dem Namen .cloudbuild/triggers.yaml.

  3. Konfigurieren Sie den Trigger in der Datei .cloudbuild/triggers.yaml:

    triggers:
- name: TRIGGER_NAME
  project: PROJECT_ID
  configFilePath: CLOUD_BUILD_CONFIG_PATH
  eventType: EVENT_TYPE
  ignoredGitRefs: IGNORED_GIT_REFS
  includedGitRefs: INCLUDED_GIT_REFS
  serviceAccount: SERVICE_ACCOUNT
  includedFiles: INCLUDED_FILES
  ignoredFiles: IGNORED_FILES
  disabled: DISABLED_BOOL
  substitutions:
    _VARIABLE_NAME: VARIABLE_VALUE
    OVERRIDE_VARIABLE_NAME: OVERRIDE_VARIABLE_VALUE

    Ersetzen Sie Folgendes:

    • TRIGGER_NAME durch einen Namen für Ihren Trigger. Triggernamen dürfen nur alphanumerische Zeichen und Gedankenstriche enthalten und nicht mit einem Gedankenstrich beginnen oder enden. Triggernamen dürfen maximal 63 Zeichen lang sein.
    • PROJECT_ID durch die Google Cloud Projekt-ID des Projekts, in dem Sie Cloud Build aktiviert haben. Dieses Feld ist optional. Der Standardwert ist das Secure Source Manager-Projekt.
    • CLOUD_BUILD_CONFIG_PATH durch den Pfad zur Cloud Build-Konfigurationsdatei, die Sie für diesen Trigger verwenden möchten. Dieses Feld ist optional. Der Standardwert ist .cloudbuild/cloudbuild.yaml.

    • EVENT_TYPE durch den Ereignistyp, mit dem Sie den Build auslösen möchten. Folgende Optionen sind verfügbar:

      • push zum Auslösen bei einem Push in die angegebenen Zweige
      • pull_request zum Auslösen bei einem Pull-Request in die angegebenen Zweige

      Dieses Feld ist optional. Der Standardwert ist push.

    • INCLUDED_GIT_REFS durch einen optionalen regulären RE2-Ausdruck, der mit den Git-Referenzen übereinstimmt, mit denen Sie einen Build auslösen möchten. Der Standardwert ist leer. Ein leerer Wert bedeutet, dass es keine Einschränkungen gibt.

    • IGNORED_GIT_REFS durch einen optionalen regulären Ausdruck im RE2-Format, der mit den Git-Referenzen übereinstimmt, mit denen Sie keinen Build auslösen möchten. Der Standardwert ist leer. Ein leerer Wert bedeutet, dass es keine Einschränkungen gibt. Das Feld ignoredGitRefs wird vor dem Feld includedGitRefs geprüft. Weitere Informationen zu diesen Feldern finden Sie unter Triggers file schema (Schemadatei für Trigger).

    • SERVICE_ACCOUNT durch das Cloud Build-Dienstkonto, das für den Build verwendet werden soll, im Format projects/PROJECT_ID/serviceAccounts/ACCOUNT. Ersetzen Sie ACCOUNT durch die E-Mail-Adresse oder eindeutige ID des Dienstkontos. Sie können entweder das Cloud Build-Standarddienstkonto oder ein nutzerverwaltetes Dienstkonto verwenden. Das alte Cloud Build-Dienstkonto kann aufgrund seiner Einschränkungen nicht verwendet werden.

    • INCLUDED_FILES durch einen optionalen regulären Ausdruck im RE2-Format, der mit den Dateien übereinstimmt, mit denen Sie einen Build auslösen möchten.

      Wenn keine der geänderten Dateien mit dem Filterfeld ignoredFiles übereinstimmt und die geänderten Dateien mit dem Filterfeld includedFiles übereinstimmen, wird ein Build ausgelöst. Der Standardwert ist leer. Ein leerer Wert bedeutet, dass es keine Einschränkungen gibt.

    • IGNORED_FILES durch einen optionalen regulären Ausdruck im RE2-Format, der mit den Dateien übereinstimmt, mit denen Sie keinen Build auslösen möchten.

      Wenn alle geänderten Dateien in einem Commit mit diesem Filterfeld übereinstimmen, wird kein Build ausgelöst. Der Standardwert ist leer. Ein leerer Wert bedeutet, dass es keine Einschränkungen gibt.

    • DISABLED_BOOL durch true, um den Trigger zu deaktivieren, oder false, um den Trigger zu aktivieren. Dieses Feld ist optional. Der Standardwert ist false.

    • VARIABLE_NAME durch den Namen einer Variablen, die Sie in Ihre Triggerdatei einfügen möchten.

    • VARIABLE_VALUE durch den Wert der Variablen.

    • OVERRIDE_VARIABLE_NAME durch den Standardnamen der Secure Source Manager-Substitutionsvariablen. Informationen zu den verfügbaren Standard-Substitutionsvariablen finden Sie im Abschnitt zu Substitutionen unter Triggers file schema (Schemadatei für Trigger).

    • OVERRIDE_VARIABLE_VALUE durch den Wert, mit dem Sie den Standardwert für die Standard-Substitutionsvariable überschreiben möchten.

  4. Übertragen Sie die Triggerkonfigurationsdatei in Ihren Standardzweig.

    Nachdem die Triggerdatei übertragen wurde, löst Secure Source Manager Builds basierend auf der Konfiguration in Ihrer Triggerdatei aus.

    Secure Source Manager liest die Konfigurationsdateien und die zugehörige Commit-SHA oder Git-Referenz der folgenden Ereignistypen:

    • Bei push-Ereignissen liest Secure Source Manager die Commit-SHA oder Git-Referenz, wenn der Push abgeschlossen ist.
    • Bei pull_request-Ereignissen liest Secure Source Manager die Commit-SHA oder Git-Referenz, wenn die Änderungen des Pull-Requests abgerufen wurden.

Build-Status ansehen

Wenn ein Build durch ein Push- oder Pull-Request-Ereignis ausgelöst wird, werden der Commit- und der Build-Status in der Secure Source Manager-Weboberfläche angezeigt.

Die möglichen Werte für den Build-Status sind:

  • ErfolgreichERFOLG: Der Build wurde erfolgreich abgeschlossen.
  • WarnungWARNUNG: Beim Erstellen des Builds ist ein Problem aufgetreten.
  • FehlerFEHLER: Der Build ist während der Ausführung fehlgeschlagen.

Sie können verhindern, dass Commits mit nicht erfolgreichen Builds in wichtige Zweige zusammengeführt werden, indem Sie eine Zweigschutzregel konfigurieren, die eine erfolgreiche Statusprüfung von Triggern erfordert, die in Ihrer Triggerdatei konfiguriert sind. Weitere Informationen zum Zweigschutz finden Sie unter Zweigschutz – Übersicht.

So rufen Sie den Build-Status für ein Push-Ereignis auf:

  1. Rufen Sie in der Secure Source Manager-Weboberfläche Ihr Repository auf.

    Wenn das letzte Push-Ereignis einen Build ausgelöst hat, wird der Status neben der Commit-SHA angezeigt. Klicken Sie auf den Status, um Details dazu aufzurufen.

  2. Wenn Sie den Build-Status für frühere Commits aufrufen möchten, wählen Sie Commits aus, um den Commit-Verlauf aufzurufen, und klicken Sie dann auf den Status, für den Sie Details aufrufen möchten.

So rufen Sie den Build-Status für ein Pull-Request-Ereignis auf:

  1. Klicken Sie in der Secure Source Manager-Weboberfläche auf Pull-Requests.

  2. Klicken Sie auf den Pull-Request, den Sie aufrufen möchten.

    Wenn Builds durch den Pull-Request ausgelöst wurden, wird ein Abschnitt mit dem Titel entweder Alle Prüfungen waren erfolgreich oder Bei einigen Prüfungen wurden Warnungen gemeldet angezeigt.

Nächste Schritte