Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Mit Cloud Build verbinden

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

Standardmäßig verwendet Secure Source Manager einen von Google verwalteten Dienst-Agent, um mit Cloud Build und anderen Ressourcen zu interagieren. Um Teamberechtigungen zu isolieren, empfehlen wir, eine Identität pro Repository zu konfigurieren, indem Sie Ihrem Repository ein nutzerverwaltetes Dienstkonto zuweisen. Secure Source Manager verwendet das nutzerverwaltete Dienstkonto, das mit dem Repository verknüpft ist, um Builds auszulösen.

Im Gegensatz zum Standarddienst-Agent können Sie ein vom Nutzer verwaltetes Dienstkonto mit der Berechtigung iam.serviceAccounts.actAs für benutzerdefinierte Cloud Build-Dienstkonten konfigurieren. So können Sie Builds mit benutzerdefinierten Dienstkonten ausführen und gleichzeitig die Build-Berechtigungen auf dieses Repository beschränken.

Hinweis

Secure Source Manager-Instanz erstellen
Secure Source Manager-Repository erstellen
Benutzerdefiniertes Dienstkonto für Cloud Build konfigurieren. Damit Cloud Build aus Ihrem Secure Source Manager-Repository lesen kann, weisen Sie dem Cloud Build-Dienstkonto (entweder dem Standarddienstkonto oder einem nutzerverwalteten Dienstkonto) die folgenden Rollen zu:
- Auf Secure Source Manager-Instanzen zugreifende Person (roles/securesourcemanager.instanceAccessor) für die Secure Source Manager-Instanz.
- Secure Source Manager Repository Reader für das Repository.
Je nach Anwendungsfall benötigt das Cloud Build-Dienstkonto möglicherweise zusätzliche Rollen, z. B.:
- Zum Speichern von Build-Logs in Cloud Logging weisen Sie dem Cloud Build-Dienstkonto die Rolle Logautor (roles/logging.logWriter) zu.
- Damit auf 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 zu Build-Logs finden Sie unter Build-Logs einrichten.
Wenn Ihre Builds in Worker-Pools ausgeführt werden, weisen Sie dem vom Nutzer verwalteten Dienstkonto des Repositorys die Rolle Cloud Build WorkerPool User (roles/cloudbuild.workerPoolUser) in dem Projekt zu, in dem die Builds ausgeführt werden.

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

Wenn Sie Secure Source Manager mit Cloud Build verbinden möchten, müssen Sie IAM-Berechtigungen für eine Identität pro Repository konfigurieren.

Identitätseinrichtung pro Repository

Wenn Sie eine Identität pro Repository verwenden möchten, müssen Sie Berechtigungen konfigurieren.

Nutzer: Der Nutzer, der das Dienstkonto für das Repository konfiguriert, benötigt die Rolle Dienstkontonutzer (roles/iam.serviceAccountUser) für das vom Nutzer verwaltete Dienstkonto. Diese Berechtigung wird beim Erstellen oder Aktualisieren des Repositorys geprüft.
Secure Source Manager-Dienst-Agent: Weisen Sie dem Secure Source Manager-Dienst-Agent für das Repository-Projekt die Rolle Ersteller von Dienstkonto-Tokens (roles/iam.serviceAccountTokenCreator) für das nutzerverwaltete Dienstkonto zu.

Die E-Mail-Adresse des Secure Source Manager-Dienst-Agents hat das Format service-REPOSITORY_PROJECT_NUMBER@gcp-sa-sourcemanager.iam.gserviceaccount.com, wobei REPOSITORY_PROJECT_NUMBER die Projektnummer des Projekts ist, in dem sich das Repository befindet.
Nutzerverwaltetes Dienstkonto:
- Weisen Sie dem vom Nutzer verwalteten Dienstkonto die Rolle Dienstkontonutzer (roles/iam.serviceAccountUser) für das benutzerdefinierte Cloud Build-Dienstkonto (im Repository-Projekt) zu.
- Weisen Sie dem nutzerverwalteten Dienstkonto die Rolle Cloud Build-Bearbeiter (roles/cloudbuild.builds.editor) und die Rolle Service Usage Consumer (roles/serviceusage.serviceUsageConsumer) für das Projekt zu, in dem Builds ausgeführt werden.

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

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 Trigger-Konfigurationsdatei 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 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 stehen zur Verfügung:
  - push, um den Trigger bei einem Push zum angegebenen Branch oder den angegebenen Branches auszulösen
  - pull_request, um bei einer Pull-Anfrage für die angegebenen Branches 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 keine Einschränkungen gelten. Das Feld ignoredGitRefs wird vor dem Feld includedGitRefs geprüft. Weitere Informationen zu diesen Feldern finden Sie unter Schema der Triggerdatei.
- 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. Sie können entweder das Cloud Build-Standarddienstkonto oder ein nutzerverwaltetes Dienstkonto verwenden. Das Legacy-Dienstkonto von Cloud Build kann aufgrund seiner Einschränkungen nicht verwendet werden.
- INCLUDED_FILES mit einem optionalen regulären RE2-Ausdruck, 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 Ihre Triggerdatei aufnehmen möchten.
- VARIABLE_VALUE durch den Wert der Variablen.
- OVERRIDE_VARIABLE_NAME durch den Namen der Standard-Substitutionsvariablen von Secure Source Manager. Informationen zu den verfügbaren Standard-Substitutionsvariablen finden Sie im Abschnitt „Substitutions“ des Triggers file schema (Schema für Triggerdateien).
- 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 eine erfolgreiche Statusprüfung 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. Klicken Sie auf den Status, um Details dazu aufzurufen.
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 ansehen 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.