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.

Haben Sie sich die Build-Logs angesehen?

Verwenden Sie Logging- oder Cloud Storage-Build-Logs, um weitere Informationen zum Build-Fehler zu erhalten. Logs, die in stdout oder stderr geschrieben wurden 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:

Builds schlagen fehl, da Dienstkontoberechtigungen fehlen

Wenn das Dienstkonto, das Sie für Ihren Build verwenden, nicht die erforderlichen Berechtigungen zum Ausführen einer Aufgabe hat, wird möglicherweise ein Fehler wie der folgende angezeigt:

Missing necessary permission iam.serviceAccounts.actAs for [USER] on the service account [SERVICE ACCOUNT]

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 Build-Dienstkonto gewährt werden soll:

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

Fehler „Berechtigung verweigert“ beim Bereitstellen in Cloud Run-Funktionen

Wenn Sie versuchen, Cloud Run-Funktionen 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 Build-Dienstkonto die Rolle „Cloud Run-Entwickler“ zuweisen.

Fehler „Fehlende Berechtigung“ bei der Bereitstellung in Cloud Run-Funktionen

Bei der Bereitstellung in Cloud Run-Funktionen wird möglicherweise der folgende Fehler angezeigt:

Missing necessary permission iam.serviceAccounts.actAs for [USER] on the service account [SERVICE ACCOUNT]

Weisen Sie die Rolle „Dienstkontonutzer“ entweder dem vom Nutzer angegebenen Dienstkonto oder dem Standarddienstkonto zu, um diesen Fehler zu beheben.

Fehler bei der Bereitstellung in App Engine

Bei der Bereitstellung in App Engine wird möglicherweise der folgende Fehler angezeigt:

Missing necessary permission iam.serviceAccounts.actAs for [USER] on the service account [SERVICE_ACCOUNT]

Zum Beheben dieses Fehlers weisen Sie entweder dem benutzerdefinierten Dienstkonto oder dem Standarddienstkonto die Rolle „App Engine-Administrator“ zu.

Fehler beim Bereitstellen in GKE

Bei der Bereitstellung in GKE wird in etwa der folgende Fehler angezeigt:

Missing necessary permission iam.serviceAccounts.actAs for [USER] on the service account [SERVICE_ACCOUNT]

Zum Beheben dieses Fehlers weisen Sie dem Build-Dienstkonto die Rolle „GKE-Entwickler“ zu.

Fehler bei der Bereitstellung in Cloud Run

Bei der Bereitstellung in Cloud Run wird in etwa der folgende Fehler angezeigt:

Missing necessary permission iam.serviceAccounts.actAs for [USER] on the service account [SERVICE_ACCOUNT]

Dieser Fehler wird angezeigt, weil das 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.

Build-Trigger schlägt aufgrund einer fehlenden cloudbuild.builds.create-Berechtigung fehl

Beim Ausführen eines Build-Triggers wird in etwa 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 ein Dienstkonto, um einen Build zu erstellen. Dieser Fehler gibt an, dass dem 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 der Cloud Build Service Account IAM-Rolle entweder für das benutzerdefinierte Dienstkonto oder das Standarddienstkonto.

Einreichen des Builds fehlgeschlagen, da Berechtigungen für den Kundenservicemitarbeiter fehlen

Wenn der Cloud Build-Dienst-Agent gelöscht wurde oder keine Berechtigungen hat, kann beim Einreichen eines Builds der folgende Fehler auftreten.

Caller does not have required permission to use project $PROJECT_ID. Grant the caller the roles/serviceusage.serviceUsageConsumer role, or a custom role with the serviceusage.services.use permission, by visiting https://console.developers.google.com/iam-admin/iam/project?project=$PROJECT_ID and then retry. Propagation of the new permission may take a few minutes.

Der Aufrufer in diesem Szenario ist der Cloud Build-Dienst-Agent. Bis beheben Sie dieses Berechtigungsproblem:

  1. Prüfen Sie, ob der Cloud Build-Dienst-Agent vorhanden ist. Sie können den Dienst-Agent für ein Projekt aufrufen. Dazu rufen Sie die Seite IAM in der Google Cloud Console auf und klicken auf das Kästchen Von Google verwaltete Dienstkonten anzeigen. Wenn nicht vorhanden ist, können Sie sie mit folgendem Befehl erstellen: gcloud CLI-Befehlszeile:

    gcloud beta services identity create --service=cloudbuild.googleapis.com \
    --project=PROJECT_ID

  2. Weisen Sie dem Cloud Build-Dienst-Agent die IAM-Rolle roles/cloudbuild.serviceAgent zu:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com" \
    --role="roles/cloudbuild.serviceAgent"

Wenn Sie prüfen möchten, welche IAM-Identität möglicherweise für das Berechtigungsproblem des Kundenservicemitarbeiters verantwortlich ist, gehen Sie so vor:

  1. Öffnen Sie den Log-Explorer in der Google Cloud Console:

    Zum Log-Explorer

  2. Geben Sie in das Abfragefeld den folgenden Text ein:

    resource.type="project"
log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"
"service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com"

  3. Wenn Sie nach der Verwendung dieser Abfrage Logeinträge sehen, prüfen Sie, ob Er entfernt Berechtigungen vom Dienst-Agent. (service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com). Ist dies der Fall, sehen Sie sich die protoPayload.authenticationInfo.principalEmail in diesem Log an, um die IAM-Identität zu ermitteln, die für das Entfernen der Berechtigung oder der Rolle roles/cloudbuild.serviceAgent mit der im Fehlermeldung erhalten.

Trigger schlägt mit dem Fehler Couldn't read commit fehl

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

  Failed to trigger build: Couldn't read commit

Cloud Build gibt diese Meldung zurück, wenn Sie versuchen, einen Build mit einem nicht vorhandenen Branch auszulösen. Verzeichnisnamen auf Rechtschreibung prüfen und Beständigkeit. Eine Anleitung zum Einrichten von Triggern finden Sie unter Build-Trigger erstellen und verwalten.

Pub/Sub-Trigger kann nicht erstellt werden

Beim Erstellen eines Pub/Sub-Triggers wird der folgende Fehler angezeigt:

  Failed to create trigger: Request is prohibited by organization's policy

Dieser Fehler gibt an, dass die Pub/Sub API in Ihrem Projekt eingeschränkt ist. Bei Projekten, in denen die Pub/Sub API eingeschränkt ist, können keine Push-Abos erstellt werden. Sie können Pub/Sub vorübergehend aus eingeschränkten Diensten entfernen in Ihren Perimeter, erstellen Sie den Trigger und schränken Sie die Pub/Sub API ein. um den Fehler zu beheben.

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 Ihr Build-Dienstkonto die Rolle „Storage-Administrator“ haben, die zum Speichern von Container-Images erforderlich ist Container Registry

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.

Die Verbindung zur externen Ressource schlägt fehl, da keine externe IP-Adresse aktiviert ist

Wenn Sie über einen privaten Pool eine Verbindung zu einer externen Ressource herstellen, wird der folgende Fehler angezeigt:

 Failed to connect to <external_domain>: Connection timed out

Private Pools verwenden externe IP-Adressen, um auf öffentliche Ressourcen zuzugreifen wie externe Repositories. Beim Erstellen oder Aktualisieren einen privaten Pool haben, klicken Sie das Kästchen an, um Ihrem privaten Pool externe IP-Adressen zuzuweisen -Pools. Eine Anleitung zum Erstellen oder Aktualisieren von Feldern in Ihrem privaten Pool finden Sie unter Private Pools erstellen und verwalten.

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 kann auftreten, wenn der Build versucht, auf Ressourcen in einem privaten Netzwerk zuzugreifen, dies aber fehlschlägt. Standardmäßig können über Cloud Build ausgeführte Builds auf private Ressourcen im öffentlichen Internet zugreifen, z. B. auf Ressourcen in einem Repository oder einer Registry. Builds können jedoch nur auf Ressourcen in einem privaten Netzwerk zugreifen, private Pools verwenden und diese für den Zugriff auf das private Netzwerk konfigurieren. Weitere Informationen finden Sie unter Cloud Build in einem privaten Netzwerk verwenden.

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 Kurzem nach der Installation der GitHub-Anwendung ein neues Repository hinzugefügt und Cloud Build hat keine Berechtigungen für den Zugriff auf das neue Repository. Verbinden Sie in diesem Fall Ihr neues Repository mit Cloud Build.
  • Sie müssen Ihrem Build-Dienstkonto eine weitere Berechtigung erteilen.

Build schlägt aufgrund von Kontingenteinschränkungen fehl

Der folgende Fehler weist darauf hin, dass ein Build aufgrund für Kontingentbeschränkungen in einer bestimmten Region:

Failed to trigger build: generic::failed_precondition: due to quota restrictions, cannot run builds in this region. Please contact support.

Wenden Sie sich an den Cloud Customer Care, um Ihre Kontingente für diese Region erhöhen zu lassen. Weitere Informationen zu Kontingenten und Limits finden Sie unter Kontingente und Limits.

Zeitüberschreitungsprobleme beim Abrufen von Images aus der Docker-Registry

Nach einem Lauf werden in Ihrem Cloud Build-Protokoll die folgenden Zeitüberschreitungsfehler angezeigt:

Step #0: Pulling image: python:3.8.16-alpine3.17
Step #0: Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Step 1/7 : FROM python:3.8.16-alpine3.17
Get "https://registry-1.docker.io/v2/": dial tcp 34.205.13.154:443: i/o timeout

Um den Fehler zu beheben, laden Sie das Docker-Image mit Crane herunter und laden das Image dann in das Cloud Build-Docker-Image.

Fügen Sie das folgende Snippet in die Datei cloudbuild.yaml ein.

...
  # Crane runs as a regular user so we need to allow it to access the directory where it saves the image.
  - name: gcr.io/cloud-builders/docker
    args:
    - a+w
    - /workspace
    entrypoint: chmod
  # Use crane to download the image through the proxy
  - name: gcr.io/go-containerregistry/crane
    env: - 'HTTPS_PROXY=HTTPS_PROXY'
    args:
    - pull
    - 'python:3.8.16-alpine3.17'
    - /workspace/image.tar
  # Use docker load to add the image into the local Cloud Build registry
  - name: gcr.io/cloud-builders/docker
    args: [load, --input, "/workspace/image.tar"]
      - .
  • HTTPS_PROXY: Die Adresse Ihres HTTP-Proxys (z.B. https://proxy.example.com:8888/).

Sobald das Image geladen ist, sollten die vorhandenen Schritte in der Datei „cloudbuild.yaml“ wie gewohnt funktionieren, z. B.

...
  - name: python:3.8.16-alpine3.17
    args:
    - echo
    - hello
    entrypoint: bash
  # Or use it internally on a Dockerfile
  - name: gcr.io/cloud-builders/docker
    args:
    - build

Unauthenticated-Fehler bei lang laufenden Docker-Schritten

Buildschritte, die einen Docker-Befehl umfassen, der länger als eine Stunde läuft (z. B. das Pushen eines großen Images in die Artifact Registry), können mit einem Authentifizierungsfehler fehlschlagen. Cloud Build aktualisiert Authentifizierungstokens jede Stunde. Docker kann diese neuen Tokens jedoch möglicherweise nicht abrufen, was zu Authentifizierungsproblemen führt. Sie können Schreiben Sie Ihr eigenes Token mit einer benutzerdefinierten Lebensdauer, um es zu speichern und darauf zu verweisen. Docker-Befehle

In der Warteschlange befindliche Builds in einem privaten Pool, der mit einem VPC-Netzwerk verbunden ist

Wenn Sie Builds in einem privaten Pool mit seinem Netzwerk des Diensterstellers ausführen mit Ihrem eigenen VPC-Netzwerk verbunden ist, muss die private Verbindung zwischen diesen beiden Netzwerken intakt bleibt. Wenn Sie die private Verbindung löschen, auf die ein privater Pool angewiesen ist, kann der private Pool nicht mehr verwendet werden. Dies kann die so lange in der Warteschlange stehen, bis eine Zeitüberschreitung auftritt. Wenn Sie also eine private Verbindung löschen möchten, müssen Sie auch alle privaten Pools löschen, deren Diensterstellernetzwerk über diese private Verbindung mit Ihrem eigenen VPC-Netzwerk verbunden war.

Versuch, ausstehende Builds zu genehmigen oder abzulehnen, die älter als 2 Monate sind

Sie können keine ausstehenden Builds genehmigen oder ablehnen, die älter als 2 Monate sind. Dies kann zu einer Fehlermeldung wie der folgenden führen:

 404, "message": "Requested entity was not
found.", "status": "NOT_FOUND" } }

Versuchen Sie in diesem Fall, einen neuen Build einzureichen.

Nächste Schritte