Diese Seite wurde von der Cloud Translation API übersetzt.

Mit Cloud Build verbinden

Auf dieser Seite wird beschrieben, wie Sie Builds automatisch über Secure Source Manager aufrufen. Dazu verwenden Sie Cloud Build-Konfigurationsdateien und eine YAML-Datei mit Triggern in Ihrem Secure Source Manager-Repository.

Hinweise

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Verbinden eines Secure Source Manager-Repositorys mit Cloud Build benötigen:

Autor von Secure Source Manager-Repositories (roles/securesourcemanager.repoWriter) für Ihr Repository
Auf Secure Source Manager-Instanzen zugreifende Person (roles/securesourcemanager.instanceAccessor) in der Secure Source Manager-Instanz

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.

Informationen zum Zuweisen von Secure Source Manager-Rollen finden Sie unter Zugriffssteuerung mit IAM und Nutzern Instanzzugriff gewähren.

Erforderliche Dienstkontorollen

Damit Sie Builds erstellen und den Build-Status von Cloud Build abrufen können, weisen Sie dem Secure Source Manager-Dienst-Agent (service-PROJECT-NUMBER@gcp-sa-sourcemanager.iam.gserviceaccount.com) die folgenden IAM-Rollen (Identity and Access Management) zu:

Die Rolle Cloud Build-Bearbeiter (roles/cloudbuild.builds.editor) für das Projekt, in dem Sie Cloud Build aktiviert haben.
Rolle Dienstkontonutzer (roles/iam.serviceAccountUser) für das Cloud Build-Dienstkonto oder das Projekt, mit dem das Cloud Build-Dienstkonto erstellt wurde.
Wenn sich das Projekt, in dem Sie Cloud Build aktiviert haben, von dem Projekt unterscheidet, in dem Secure Source Manager aktiviert ist, weisen Sie dem Cloud Build-Projekt die Rolle Service Usage Consumer (roles/serviceusage.serviceUsageConsumer) zu.
Wenn die Builds in Worker-Pools ausgeführt werden, weisen Sie dem Secure Source Manager-Dienstkonto die Rolle Cloud Build WorkerPool User (roles/cloudbuild.workerPoolUser) im Cloud Build-Projekt zu.

Damit Cloud Build aus Ihrem Secure Source Manager-Repository lesen kann, weisen Sie dem Cloud Build-Dienstkonto die folgenden IAM-Rollen zu:

Rolle Auf Secure Source Manager-Instanzen zugreifende Person (roles/securesourcemanager.instanceAccessor) für die Secure Source Manager-Instanz.
Die Rolle Secure Source Manager Repository Reader für das Secure Source Manager-Repository, das Sie mit Cloud Build verbinden möchten.

Je nach Anwendungsfall benötigt das Cloud Build-Dienstkonto möglicherweise zusätzliche IAM-Rollen zum Ausführen von Builds, z. B.:

Zum Speichern von Build-Logs in Cloud Logging weisen Sie dem Cloud Build-Dienstkonto die Rolle Logautor zu.
Damit auf die Secrets in Secret Manager zugegriffen werden kann, weisen Sie dem Cloud Build-Dienstkonto die Rolle Zugriffsperson für Secret Manager-Secret (roles/secretmanager.secretAccessor) zu.

Informationen zum Zuweisen von IAM-Rollen zu einem Dienst-Agent finden Sie unter Einzelne Rolle zuweisen oder widerrufen.

Informationen zu Build-Logs finden Sie unter Build-Logs einrichten.

Build-Konfigurationsdatei erstellen

Eine Build-Konfigurationsdatei definiert die Felder, die Cloud Build zur Ausführung Ihrer Build-Aufgaben benötigt. Sie können die Build-Konfigurationsdatei in der YAML-Syntax schreiben.

Sie können Build-Konfigurationsdateien in den Branches erstellen, aus denen Sie den Build erstellen möchten.

So erstellen Sie eine Build-Konfigurationsdatei:

Wählen Sie in der Secure Source Manager-Weboberfläche das Repository aus, das Sie mit Cloud Build verbinden möchten.
Wählen Sie den Branch aus, aus dem Sie mit Cloud Build einen Build erstellen möchten.
Erstellen Sie eine Build-Konfigurationsdatei. Eine Anleitung zum Erstellen von Build-Konfigurationsdateien finden Sie unter Build-Konfigurationsdatei erstellen.
Übernehmen Sie die Änderungen für den Zweig.

Triggerdatei erstellen

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

So erstellen Sie eine Konfigurationsdatei für Trigger:

Wechseln Sie in Ihrem lokalen Repository oder in der Secure Source Manager-Weboberfläche zum Standardzweig.
Erstellen Sie eine Datei mit dem Namen .cloudbuild/triggers.yaml.
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.
Ü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:

SUCCESS: Der Build wurde erfolgreich abgeschlossen.
WARNUNG: Beim Erstellen ist ein Problem aufgetreten.
FAILURE: 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:

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

Klicken Sie in der Secure Source Manager-Weboberfläche auf Pull Requests.
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.

Fehlerbehebung

Methoden zur Diagnose und Behebung von Cloud Build-Fehlern bei der Verbindung mit Secure Source Manager finden Sie unter Triggerdatei löst keinen Build aus.

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