Build-Fehler beheben

Auf dieser Seite werden Strategien zur Fehlerbehebung sowie Lösungen für häufige Fehlermeldungen beschrieben, die beim Ausführen eines Builds auftreten können.

Wird Ihr Build lokal weitergeleitet?

Beim Beheben von Cloud Build-Fehlern sollten Sie als ersten Schritt überprüfen, ob die Builds lokal erstellt werden können. Wenn der Build nicht lokal funktioniert, wird die Ursache des Problems nicht durch Cloud Build verursacht. Sie müssen das Problem dann zuerst lokal diagnostizieren und beheben.

Haben Sie sich die Build-Logs angesehen?

Verwenden Sie Logging- oder Cloud Storage-Build-Logs, um weitere Informationen zum Build-Fehler zu erhalten. In stdout oder stderr geschriebene Logs werden automatisch in der Cloud Console angezeigt.

Manuelle Builds schlagen fehl, da der Nutzer keinen Zugriff auf die Build-Logs hat

Der folgende Fehler wird angezeigt, wenn Sie versuchen, einen Build manuell auszuführen:

AccessDeniedAccess denied. [EMAIL_ADDRESS] does not have storage.objects.get access to the Google Cloud Storage object.

Dieser Fehler wird angezeigt, da Cloud Build erfordert, dass Nutzer manuelle Builds und dieStandard-Bucket von Cloud Storage-Logs die Rolle "Projektbetrachter" sowie die Rolle "Cloud Build-Bearbeiter" haben. Sie haben folgende Möglichkeiten, um diesen Fehler zu beheben:

Builds schlagen fehl, da Dienstkontoberechtigungen fehlen

Cloud Build verwendet ein spezielles Dienstkonto, um Builds für Sie auszuführen. Wenn das Cloud Build-Dienstkonto nicht die erforderlichen Berechtigungen zum Ausführen einer Aufgabe hat, wird der folgende Fehler angezeigt:

Missing necessary permission iam.serviceAccounts.actAs for [USER] on the service account [CLOUD_BUILD_SERVICE_ACCOUNT]@PROJECT.iam.gserviceaccount.com

Erteilen Sie dem Dienstkonto die erforderliche Berechtigung, um diesen Fehler zu beheben. Verwenden Sie die Informationen auf den folgenden Seiten, um die Berechtigung zu bestimmen, die dem Cloud Build-Dienstkonto gewährt werden soll:

Build-Fehler aufgrund fehlender Berechtigungen für ein Dienstkonto treten häufig auf, wenn Sie versuchen, eine Bereitstellung mit Cloud Build durchzuführen.

Fehler beim Bereitstellen in Cloud Functions

Bei der Bereitstellung in Cloud Functions wird folgender Fehler angezeigt:

Missing necessary permission iam.serviceAccounts.actAs for [USER] on the service account [CLOUD_BUILD_SERVICE_ACCOUNT]@PROJECT.iam.gserviceaccount.com

Sie können diesen Fehler beheben, indem Sie dem Cloud Build-Dienstkonto die Cloud Functions-Entwicklerrolle zuweisen.

Fehler bei der Bereitstellung in App Engine

Bei der Bereitstellung in App Engine tritt der folgende Fehler auf:

Missing necessary permission iam.serviceAccounts.actAs for [USER] on the service account [CLOUD_BUILD_SERVICE_ACCOUNT]@PROJECT.iam.gserviceaccount.com

Zum Beheben dieses Fehlers weisen Sie dem Cloud Build-Dienstkonto die Rolle "App Engine-Administrator" zu.

Fehler beim Bereitstellen in GKE

Bei der Bereitstellung in GKE wird folgender Fehler angezeigt:

Missing necessary permission iam.serviceAccounts.actAs for [USER] on the service account [CLOUD_BUILD_SERVICE_ACCOUNT]@PROJECT.iam.gserviceaccount.com

Zum Beheben dieses Fehlers weisen Sie dem Cloud Build-Dienstkonto die GKE-Entwicklerrolle zu.

Fehler bei der Bereitstellung in Cloud Run

Bei der Bereitstellung in Cloud Run wird folgender Fehler angezeigt:

Missing necessary permission iam.serviceAccounts.actAs for [USER] on the service account [CLOUD_BUILD_SERVICE_ACCOUNT]@PROJECT.iam.gserviceaccount.com

Dieser Fehler wird angezeigt, weil das Cloud Build-Dienstkonto nicht die erforderlichen IAM-Berechtigungen für die Bereitstellung in Cloud Run hat. Weitere Informationen zum Gewähren der erforderlichen Berechtigungen finden Sie unter In Cloud Run bereitstellen.

Fehler beim Speichern von Images in Container Registry

Der folgende Fehler wird angezeigt, wenn Ihr Build versucht, erstellte Images in Container Registry zu speichern:

[EMAIL_ADDRESS] does not have storage.buckets.create access to project [PROJECT_NAME]

Dieser Fehler wird angezeigt, weil das Cloud Build-Dienstkonto nicht die Rolle Storage-Administrator hat, die zum Speichern von Container-Images in Container Registry erforderlich ist.

Builds schlagen aufgrund einer ungültigen SSH-Autorisierung fehl

Beim Ausführen eines Builds wird der folgende Fehler angezeigt:

Could not parse ssh: [default]: invalid empty ssh-agent socket, make sure SSH_AUTH_SOCK is set

Dieser Fehler weist auf ein Problem mit der SSH-Autorisierung hin. Ein häufiges Beispiel ist ein SSH-Autorisierungsfehler, der beim Zugriff auf private GitHub-Repositories mit Cloud Build auftritt. Eine Anleitung zum Einrichten von SSH für GitHub finden Sie unter Auf private GitHub-Repositories zugreifen.

Builds schlagen wegen eines No route to host-Fehlers fehl

Wenn Sie einen Build in einem privaten Pool ausführen, wird der folgende oder ähnliche Fehler angezeigt:

Unable to connect to the server: dial tcp 192.168.10.XX:<port>: connect: no route to host

Cloud Build führt seine Cloud-Builder auf der virtuellen Maschine im von Google verwalteten Projekt aus und verwendet die Docker-Container. Die Docker-Bridge-Schnittstelle (und damit die mit dieser Schnittstelle verbundenen Container) erhält den IP-Bereich 192.168.10.0/24, wodurch die Kommunikation mit den externen Hosts im selben Subnetz unmöglich ist. Wenn Sie die IP-Bereiche für Ressourcen in Ihren Projekten während der Konfiguration des privaten Pools zuweisen, sollten Sie einen Bereich außerhalb von 192.168.10.0/24 auswählen. Eine Anleitung finden Sie unter Umgebung für private Pools einrichten.

Build-Trigger schlägt aufgrund fehlender cloudbuild.builds.create-Berechtigungen fehl

Beim Ausführen eines Build-Triggers wird der folgende Fehler angezeigt:

Failed to trigger build: Permission 'cloudbuild.builds.create' denied on resource 'projects/xxxxxxxx' (or it may not exist)

Build-Trigger verwenden das Cloud Build-Dienstkonto, um einen Build zu erstellen. Der obige Fehler weist darauf hin, dass dem Cloud Build-Dienstkonto die IAM-Berechtigung cloudbuild.builds.create fehlt, die für das Ausführen eines Build-Triggers erforderlich ist. Sie können diesen Fehler beheben, indem Sie [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com die IAM-Rolle Cloud Build Service Account zuweisen. Eine Anleitung zum Zuweisen dieser Rolle finden Sie unter Zugriff für Cloud Build-Dienstkonto konfigurieren.

E/A-Zeitüberschreitungsfehler

Beim Ausführen eines Builds wird der folgende Fehler angezeigt:

Timeout - last error: dial tcp IP_ADDRESS: i/o timeout

Dieser Fehler tritt häufig auf, wenn der Build versucht, auf Ressourcen in einem privaten Netzwerk zuzugreifen. Über Cloud Build ausgeführte Builds können auf private Ressourcen im öffentlichen Internet zugreifen, beispielsweise auf Ressourcen in einem Repository oder eine Registry. Builds können jedoch nicht auf Ressourcen in einem privaten Netzwerk zugreifen.

4xx-Clientfehler

Diese Gruppe von Fehlern gibt an, dass die Build-Anfrage aufgrund des Fehlers des Nutzers, der die Anfrage sendet, nicht erfolgreich war. Beispiele für 4xx-Clientfehler:

  • **Error**: 404 : Requested entity was not found
  • **Error**: 404 : Trigger not found
  • **Error**: 400 : Failed Precondition

Bei einem 4xx-Clientfehler sehen Sie in Ihren Build-Logs, ob diese weitere Informationen zum Grund des Fehlers enthalten. Häufige Ursachen für Clientfehler:

  • Der von Ihnen angegebene Quellspeicherort hat nichts Neues zum Commit und der Baumstruktur ist sauber. Prüfen Sie in diesem Fall den Speicherort Ihres Quellcodes und versuchen Sie es noch einmal.
  • Ihr Repository enthält keine Build-Konfigurationsdatei. Laden Sie in diesem Fall eine Build-Konfigurationsdatei in Ihr Repository hoch und führen Sie den Build noch einmal aus.
  • Sie haben eine falsche Trigger-ID angegeben.
  • Sie haben vor der Installation der GitHub-Anwendung ein neues Repository hinzugefügt und Cloud Build hat keine Zugriffsberechtigung für das neue Repository. Verbinden Sie in diesem Fall Ihr neues Repository mit Cloud Build.

Nächste Schritte