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.
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 Google 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:
Verwenden Sie den Standard-Log-Bucket und weisen Sie dem Nutzer, der den Build ausführt, die Rolle Projektbetrachter und die Rolle Cloud-Build-Bearbeiter zu. Eine Anleitung zum Gewähren dieser Berechtigung finden Sie unter Zugriff auf Cloud Build-Ressourcen konfigurieren.
Erstellen Sie einen eigenen Cloud Storage-Bucket zum Speichern von Logs. Eine Anleitung finden Sie unter Build-Logs in einem vom Nutzer erstellten Bucket speichern.
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:
- Cloud Build-Dienstkonto
- Informationen zu IAM-Rollen
- Berechtigungen für Cloud Build-Dienstkonto erteilen
Build-Fehler aufgrund fehlender Berechtigungen für ein Dienstkonto treten häufig auf, wenn Sie versuchen, eine Bereitstellung mit Cloud Build durchzuführen.
Fehler „Berechtigung verweigert“ beim Bereitstellen in Cloud Functions
Beim Versuch, Cloud Functions zu verwenden, wird der folgende Fehler angezeigt:
ResponseError: status=[403], code=[Ok], message=[Permission 'cloudfunctions.functions.get' denied
Sie können diesen Fehler beheben, indem Sie dem Cloud Build-Dienstkonto die Cloud Functions-Entwicklerrolle zuweisen.
Fehlender Berechtigungsfehler 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
Um diesen Fehler zu beheben, weisen Sie dem Cloud Build-Dienstkonto die Rolle „Dienstkontonutzer“ zu.
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 aufgrund des Fehlers No route to host fehl
Der folgende oder ein ähnlicher Fehler tritt auf, wenn Sie einen Build in einem privaten Pool ausführen:
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 mithilfe der Docker-Container aus. Der Docker-Brückenschnittstelle (und damit den mit dieser Schnittstelle verbundenen Containern) wird ein IP-Bereich von 192.168.10.0/24 zugewiesen, 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, empfehlen wir, einen Bereich außerhalb von 192.168.10.0/24 auszuwählen. Eine Anleitung finden Sie unter Umgebung für private Pools einrichten.
Verbindung zu externer Ressource schlägt fehl, da keine externe IP-Adresse aktiviert ist
Beim Herstellen einer Verbindung zu einer externen Ressource aus einem privaten Pool wird der folgende Fehler angezeigt:
Failed to connect to <external_domain>: Connection timed out
Private Pools verwenden externe IP-Adressen für den Zugriff auf Ressourcen im öffentlichen Internet, z. B. externe Repositories. Klicken Sie beim Erstellen oder Aktualisieren eines privaten Pools auf das Kästchen, um dem privaten Pool externe IP-Adressen zuzuweisen. Eine Anleitung zum Erstellen oder Aktualisieren von Feldern im privaten Pool finden Sie unter Private Pools erstellen und verwalten.
Build-Trigger schlägt aufgrund einer fehlenden cloudbuild.builds.create-Berechtigung 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 erstellen mit dem Cloud Build-Dienstkonto einen Build. Der obige Fehler gibt an, dass dem Cloud Build-Dienstkonto die IAM-Berechtigung cloudbuild.builds.create fehlt, die für das Dienstkonto erforderlich ist, um einen Build-Trigger auszuführen. 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 das 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**Error**: 403 : Permission denied
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.
- Sie müssen dem Dienstkonto eine weitere Berechtigung erteilen.