Triggerdatei erstellen

Auf dieser Seite wird beschrieben, wie Sie eine YAML-Datei für Trigger in Secure Source Manager erstellen. Mit einer Triggerdatei können Sie Builds basierend auf Push- und Pull-Anfrage-Ereignissen in einem Secure Source Manager-Repository automatisieren.

Informationen zu den Feldern, die Sie in eine Triggerdatei aufnehmen können, finden Sie unter Schema der Triggerdatei.

Hinweise

  1. Secure Source Manager-Instanz erstellen
  2. Secure Source Manager-Repository erstellen
  3. Im Schema der Triggerdatei finden Sie Informationen zu den Feldern, die Sie in eine Triggerdatei aufnehmen 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 dem Branch oder den Branches, aus denen Sie den Build 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 Standardbranch 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:

    • Ersetzen Sie TRIGGER_NAME durch einen Namen für den Trigger. Triggernamen dürfen nur alphanumerische Zeichen und Bindestriche enthalten und dürfen nicht mit einem Bindestrich beginnen oder enden. Der Triggername muss kürzer als 64 Zeichen sein.
    • Ersetzen Sie PROJECT_ID durch die Google Cloud Projekt-ID, in der Sie Cloud Build aktiviert haben. Dieses Feld ist optional. Der Standardwert ist das Secure Source Manager-Projekt.
    • CLOUD_BUILD_CONFIG_PATH mit dem 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 mit dem Ereignistyp, mit dem der Build ausgelöst werden soll. Folgende Optionen sind verfügbar:

      • push, um den Trigger bei einem Push zum angegebenen Branch oder den angegebenen Branches auszulösen
      • pull_request, um eine Pull-Anfrage für die angegebenen Zweige auszulösen

      Dieses Feld ist optional. Der Standardwert ist push.

    • INCLUDED_GIT_REFS mit einem optionalen RE2-Format für reguläre Ausdrücke, das den Git-Referenzen entspricht, für die ein Build ausgelöst werden soll. In der Standardeinstellung ist dieser Wert leer. Ein leerer Wert bedeutet, dass keine Einschränkungen gelten.

    • IGNORED_GIT_REFS mit einem optionalen regulären Ausdruck im RE2-Format, der mit den Git-Referenzen übereinstimmt, für die kein Build ausgelöst werden soll. In der Standardeinstellung ist dieser Wert 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 Schema für Trigger-Datei.

    • SERVICE_ACCOUNT mit dem 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. Als Best Practice empfehlen wir, ein benutzerdefiniertes Dienstkonto zu konfigurieren. Das Legacy-Dienstkonto von Cloud Build kann aufgrund seiner Einschränkungen nicht verwendet werden.

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

      Wenn eine der geänderten Dateien nicht mit dem Filterfeld ignoredFiles übereinstimmt und die geänderten Dateien mit dem Filterfeld includedFiles übereinstimmen, wird ein Build ausgelöst. In der Standardeinstellung ist dieser Wert leer. Ein leerer Wert bedeutet, dass keine Einschränkungen gelten.

    • IGNORED_FILES mit einem optionalen regulären Ausdruck im RE2-Format, der Dateien entspricht, für die kein Build ausgelöst werden soll.

      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 mit 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 Ihrer Triggerdatei einführen 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 „Substitutions“ des Triggers-Dateischemas.

    • 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 committet wurde, löst Secure Source Manager Builds basierend auf der Konfiguration in Ihrer Triggerdatei aus.

    Secure Source Manager liest die Konfigurationsdateien und den zugehörigen Commit-SHA oder die 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 den Commit-SHA oder die Git-Referenz, aus der die Änderungen der Pull-Anfrage abgerufen werden.

Build-Status ansehen

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

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

  • ErfolgreichSUCCESS: Der Build wurde erfolgreich abgeschlossen.
  • WarnungWARNUNG: Beim Erstellen ist ein Problem aufgetreten.
  • FehlerFAILURE: Der Build ist während der Ausführung fehlgeschlagen.

Sie können verhindern, dass Commits mit fehlgeschlagenen Builds in wichtige Branches zusammengeführt werden, wenn Sie eine Branch-Schutzregel konfigurieren, die einen erfolgreichen Statuscheck von Triggern erfordert, die in Ihrer Triggerdatei konfiguriert sind. Weitere Informationen zum Schutz von Zweigen finden Sie in der Übersicht zum Schutz von Zweigen.

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 dem Commit-SHA angezeigt. Wenn Sie Details zu diesem Status aufrufen möchten, klicken Sie auf den Status.

  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 die Pull-Anfrage, die Sie aufrufen möchten.

    Wenn Builds durch den Pull-Request ausgelöst wurden, sehen Sie einen Abschnitt mit dem Titel Alle Prüfungen waren erfolgreich oder Bei einigen Prüfungen wurden Warnungen ausgegeben.

Nächste Schritte