Build-Logs speichern und ansehen

Richten Sie Ihre Build-Konfigurationsdatei so ein, dass Ihre Build-Logs in Log-Buckets gespeichert werden, damit Sie sie mit Cloud Logging- und Cloud Storage-Tools gruppieren und analysieren können. Wenn Sie die Speicherung von Build-Logs konfigurieren, haben Sie mehr Kontrolle über die Speicherung und Analyse Ihrer Logs. Wenn Sie die Einstellungen für die Speicherung von Build-Logs nicht definieren, speichert Cloud Build sie in einem Google Cloud-verwalteten Bucket mit weniger Optionen für die Analyse von Build-Logs.

Auf dieser Seite wird beschrieben, wie Sie Build-Logs in verschiedenen Arten von Buckets speichern und wie Sie gespeicherte Logs aufrufen und löschen.

Hinweis

Sie sollten mit den Optionen der Build-Konfigurationsdatei zum Konfigurieren der Speicherung von Build-Logs vertraut sein und wissen, wie sich die Bucket-Inhaberschaft auf die Zugänglichkeit von Logs auswirkt. Weitere Informationen finden Sie unter Optionen für die Speicherung von Build-Logs.

Build-Logs in vom Nutzer erstellten Buckets speichern

Mit vom Nutzer erstellten Buckets haben Sie mehr Kontrolle über die Verwaltung und Konfiguration Ihrer Buckets.

Hinweis: Für die Speicherung von Build-Logs in Ihrem eigenen Bucket fallen Kosten an. Preisdetails finden Sie unter Cloud Storage – Preise und Cloud Logging – Preise.

Build-Logs in einem vom Nutzer erstellten Cloud Logging-Bucket speichern

Mit vom Nutzer erstellten Logging-Buckets können Sie den Aufbewahrungszeitraum für gespeicherte Build-Logs anpassen. So speichern Sie Ihre Build-Logs in einem vom Nutzer erstellten Bucket in Logging:

IAM-Berechtigungen erteilen:

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Logs Configuration Writer (roles/logging.configWriter) für das Konto oder Dienstkonto Ihres Projekts zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Speichern von Build-Logs in einem vom Nutzer erstellten Cloud Logging-Bucket 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.

Logging-Bucket konfigurieren:

1. Erstellen Sie einen Bucket und legen Sie einen Wert für das Feld Aufbewahrungszeitraum fest.

2. Erstellen Sie eine Senke um Ihre Build-Logs an Ihren neuen Bucket weiterzuleiten:

   1. Geben Sie Folgendes für den Einschlussfilter für den Build Ihrer Senke ein:

      logName = "projects/PROJECT_ID/logs/cloudbuild"
      

      Ersetzen Sie PROJECT_ID durch die Google Cloud Projekt-ID.

   2. (Optional) Wenn Sie verhindern möchten, dass Ihre Build-Logs an den standardmäßigen Logging-Bucket gesendet werden, folgen Sie dem Beispiel unter Speicherung von Logeinträgen in Log-Buckets beenden.

Build-Logs in einem vom Nutzer erstellten Cloud Storage-Bucket speichern

So speichern Sie Ihre Build-Logs in einem vom Nutzer erstellten Cloud Storage-Bucket:

IAM-Berechtigungen erteilen:

Wenn sich der Cloud Storage-Bucket und Cloud Build im selben Google Cloud Projekt befinden und Sie das Cloud Build Legacy-Dienstkontoverwenden, hat Ihr Cloud Build Legacy-Dienstkonto standardmäßig die erforderlichen IAM-Berechtigungen. Sie müssen keine zusätzlichen Berechtigungen erteilen. Gehen Sie andernfalls so vor:

Bitten Sie Ihren Administrator, Ihnen die Storage Admin (roles/storage.admin) IAM-Rolle für das Dienstkonto zuzuweisen, das für Ihren Build verwendet wird, um die Berechtigungen zu erhalten, die Sie zum Speichern von Build-Logs in einem vom Nutzer erstellten Cloud Storage-Bucket 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 Storage-Bucket konfigurieren:

1. Erstellen Sie in Ihrem Google Cloud Projekt, einen Cloud Storage-Bucket ohne festgelegte Aufbewahrungsrichtlinie, um Ihre Build-Logs zu speichern.

2. Fügen Sie in Ihrer Build-Konfigurationsdatei das Feld logsBucket hinzu, das auf den Cloud Storage-Bucket verweist, den Sie zum Speichern von Build-Logs erstellt haben. Die folgende Build-Konfigurationsdatei enthält eine Anleitung zum Erstellen eines Container-Images und zum Speichern der Build-Logs in einem Bucket namens mylogsbucket:

   YAML

       steps:
       - name: 'gcr.io/cloud-builders/docker'
         args: [ 'build', '-t', 'us-east1-docker.pkg.dev/myproject/myimage', '.' ]
       logsBucket: 'gs://mylogsbucket'
       options:
         logging: GCS_ONLY
   

   JSON

       {
         "steps": [
          {
            "name": "gcr.io/cloud-builders/docker",
            "args": [
              "build",
              "-t",
              "us-east1-docker.pkg.dev/myproject/myimage",
              "."
            ]
          }
          ],
          "logsBucket": "gs://mylogsbucket",
          "options": {
            "logging": "GCS_ONLY"
          }
       }
   

3. Verwenden Sie die Build-Konfigurationsdatei, um einen Build über die Befehlszeile, die API oder über Trigger zu starten.

Wenn der Build abgeschlossen ist, speichert Cloud Build die Build-Logs in dem Cloud Storage-Bucket, den Sie in der Build-Konfigurationsdatei angegeben haben.

Build-Logs in regionsspezifischen Cloud Storage-Buckets speichern

Sie können Ihren Build so konfigurieren, dass Cloud Build Build-Logs an einen Cloud Storage-Bucket sendet, der Ihnen gehört und sich in derselben Region wie Ihr Build befindet. Wenn Sie die Regionen Ihres Build- und Build-Log-Buckets abstimmen, können Sie die Anforderungen an den Datenstandort erfüllen.

IAM-Berechtigungen erteilen:

Wenn sich der Cloud Storage-Bucket und Cloud Build im selben Google Cloud Projekt befinden und Sie das Cloud Build Legacy-Dienstkontoverwenden, hat dieses Dienstkonto standardmäßig die erforderlichen IAM-Berechtigungen. Sie müssen keine zusätzlichen Berechtigungen erteilen. Gehen Sie andernfalls so vor:

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle „Storage Admin“ (roles/storage.admin) für das Dienstkonto zuzuweisen, das für Ihren Build verwendet wird, um die Berechtigungen zu erhalten, die Sie zum Speichern von Build-Logs in einem regionsspezifischen Bucket benötigen, der Ihnen gehört. 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.

Regionsspezifischen Cloud Storage-Bucket konfigurieren:

1. Fügen Sie in Ihrer Build-Konfigurationsdatei die Option defaultLogsBucketBehavior hinzu und legen Sie den Wert auf REGIONAL_USER_OWNED_BUCKET fest:

   YAML

   steps:
   - name: 'gcr.io/cloud-builders/docker'
     args: [ 'build', '-t', 'us-central1-docker.pkg.dev/myproject/myrepo/myimage', '.' ]
   options:
     defaultLogsBucketBehavior: REGIONAL_USER_OWNED_BUCKET
   

   JSON

   {
     "steps": [
       {
         "name": "gcr.io/cloud-builders/docker",
         "args": [
           "build",
           "-t",
           "us-central1-docker.pkg.dev/myproject/myrepo/myimage",
           "."
         ]
       }
       ],
       "options": {
         "defaultLogsBucketBehavior": "REGIONAL_USER_OWNED_BUCKET"
       }
   }
   

2. Verwenden Sie die Build-Konfigurationsdatei, um einen Build über die Befehlszeile, die API oder über Trigger zu starten.

   Wenn Sie Ihren Build ausführen, erstellt Cloud Build den neuen Bucket in der Region, in der Sie Ihren Build ausführen, und speichert dann die Build-Logs in diesem Bucket. Weitere Builds im selben Projekt und in derselben Region verwenden den vorhandenen Bucket, solange REGIONAL_USER_OWNED_BUCKET aktiv ist. Dieser Bucket gehört dem Nutzer, daher können Sie ihn so konfigurieren, als wäre er ein vom Nutzer erstellter Bucket.

   Wenn Sie die Option REGIONAL_USER_OWNED_BUCKET festlegen und Builds in mehreren Regionen erstellen, erstellt Cloud Build für jede eindeutige Region einen Cloud Storage-Bucket.

Sie können auch einen vom Nutzer erstellten Bucket verwenden, wenn Sie die Region Ihres Builds und des Log-Buckets abstimmen müssen. In diesem Fall können Sie entweder einen vorhandenen vom Nutzer erstellten Bucket mit derselben Region auswählen oder einen erstellen. Wenn Sie einen erstellen möchten, folgen Sie der Anleitung unter Build-Logs in vom Nutzer erstellten Buckets speichern und achten Sie darauf, dass der vom Nutzer erstellte Bucket dieselbe Region wie Ihr Build hat.

Build-Logs anzeigen

So rufen Sie Ihre Build-Logs auf:

IAM-Berechtigungen erteilen:

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Dienstkonto zuzuweisen, das für Ihren Build verwendet wird, um die Berechtigungen zu erhalten, die Sie zum Aufrufen von Build-Logs in Cloud Storage oder Logging benötigen:

• Build-Logs in einem vom Nutzer erstellten oder verwalteten Cloud Storage-Bucket aufrufen:
  • Storage-Objekt-Betrachter (roles/storage.objectViewer) – die Hauptkonten, die Build-Logs aufrufen möchten
  • Zugriffsberechtigter für Logbetrachtung (roles/logging.viewAccessor) – die Hauptkonten, die Build-Logs aufrufen möchten
• Build-Logs im standardmäßigen Cloud Storage-Bucket aufrufen: Betrachter (roles/viewer) – das Projekt, in dem der Build konfiguriert ist
• Build-Logs in Logging aufrufen: Logbetrachter (roles/logging.viewer) – die Hauptkonten, die Build-Logs aufrufen möchten

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.

Hinweis: Sie können die Rollen „Inhaber“ (roles/owner) oder „Bearbeiter“ (roles/editor) auf Projektebene zuweisen, damit Hauptkonten Build-Logs aus von Cloud Build erstellten und vom Nutzer verwalteten Buckets aufrufen können. Wir empfehlen jedoch, in diesem Fall die Rolle „Viewer“ zu verwenden, damit Ihre Rollenzuweisung dem Prinzip der geringsten Berechtigung entspricht. Wenn Sie die einfache Rolle „Betrachter“ nicht zuweisen möchten, verwenden Sie stattdessen vom Nutzer erstellte Buckets. Es wird insbesondere dann empfohlen, wenn Ihre Builds über Trigger aufgerufen werden und Sie nur Zugriff gewähren möchten, um Builds aufzurufen und den Fortschritt des Builds anzusehen.

Build-Logs aufrufen in Google Cloud

Console

1. Öffnen Sie die Cloud Build-Seite in der Google Cloud console.

   Zur Seite "Cloud Build"

2. Wählen Sie Ihr Projekt aus und klicken Sie auf Öffnen.

3. Wählen Sie im Drop-down-Menü Region die Region für Ihren Build aus.

4. Wählen Sie auf der Seite Build-Verlauf einen bestimmten Build aus.

5. Klicken Sie auf der Seite Build-Details unter Schritte auf Build-Zusammenfassung , um Build-Logs für den gesamten Build aufzurufen, oder wählen Sie einen Build-Schritt aus, um Build-Logs für diesen Schritt aufzurufen.

6. Wenn Ihre Build-Logs in Logging gespeichert sind, klicken Sie im Build-Log-Bereich auf das Symbol „“, um die Logs im Log-Explorer aufzurufen.

gcloud

Führen Sie den gcloud builds log Befehl aus, wobei build-id die ID des Builds ist, für den Sie Build-Logs abrufen möchten. Die Build-ID wird am Ende des Übermittlungsprozesses für den Build angezeigt, wenn Sie gcloud builds submit ausführen, oder in der Spalte „ID“, wenn Sie gcloud builds list ausführen.

gcloud builds log build-id

Build-Logs in GitHub und GitHub Enterprise aufrufen

Wenn Sie einen GitHub oder GitHub Enterprise Trigger mit der gcloud CLI oder der Cloud Build API erstellen und --include-logs-with-status als Option angegeben haben, dann können Sie Ihre Build-Logs in GitHub und GitHub Enterprise aufrufen.

So rufen Sie Build-Logs in GitHub und GitHub Enterprise auf:

1. Rufen Sie das Repository auf, das mit Ihrem Trigger verknüpft ist.

2. Rufen Sie die Liste der Commits auf.

3. Suchen Sie die Zeile des Commits, für den Sie Build-Logs aufrufen möchten.

4. Klicken Sie in der Zeile Ihres Commits auf das Ergebnissymbol.

   Daraufhin wird eine Liste der mit Ihrem Commit verknüpften Prüfungen angezeigt.

5. Klicken Sie in der Zeile, für die Sie Build-Logs aufrufen möchten, auf Details.

   Daraufhin wird die Seite Zusammenfassung für Ihren Commit angezeigt. Wenn Sie einen Trigger mit dem Flag --include-logs-with-status erstellt haben, werden Ihre Build-Logs im Bereich Details der Seite angezeigt.

Hinweis: Das Dienstkonto, das Sie für den Trigger verwendet haben, muss die Rolle roles/logging.viewer enthalten, damit die Build-Logs an GitHub gesendet werden können.

Build-Logs und Buckets löschen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Dienstkonto zuzuweisen, das für Ihren Build verwendet wird, um die Berechtigungen zu erhalten, die Sie zum Löschen von Build-Logs und Buckets in Cloud Storage benötigen:

• Build-Logs in einem vom Nutzer erstellten oder verwalteten Cloud Storage-Bucket löschen: Storage-Administrator (roles/storage.admin) – der Nutzer oder das Dienstkonto, das Build-Logs löscht
• Vom Nutzer erstellten oder verwalteten Cloud Storage-Bucket löschen: Storage-Administrator (roles/storage.admin) – der Nutzer oder das Dienstkonto, das Buckets löscht
• Vom Nutzer erstellten Logging-Bucket löschen: Logs Configuration Writer (roles/logging.configWriter) – Ihr Projekt

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.

Wenn Sie Build-Logs in einem vom Nutzer erstellten oder verwalteten Cloud Storage-Bucket löschen möchten, folgen Sie der Anleitung unter Objekte löschen in der Cloud Storage Dokumentation.

Wenn Sie einen vom Nutzer erstellten oder verwalteten Cloud Storage-Bucket löschen möchten, folgen Sie der Anleitung unter Buckets löschen in der Cloud Storage Dokumentation.

Wenn Sie einen vom Nutzer erstellten Logging-Bucket löschen möchten, folgen Sie der Anleitung unter Bucket löschen in der Logging-Dokumentation.

Nächste Schritte

• Informationen zu Audit-Logs, die von Cloud Build erstellt wurden
• Build-Ergebnisse aufrufen
• Informationen zu Cloud Build-IAM-Berechtigungen.