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. 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:

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

Beim Versuch, Cloud Run-Funktionen zu verwenden, wird folgender 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 folgender 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 folgender 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 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 die IAM-Rolle Cloud Build Service Account entweder dem vom Nutzer angegebenen Dienstkonto oder dem Standarddienstkonto zuweisen.

Build-Einreichung fehlgeschlagen, da Dienst-Agent keine Berechtigungen hat

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. So 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. Falls nicht, können Sie ihn mit dem folgenden gcloud CLI-Befehl erstellen:

    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 in einem davon Berechtigungen vom Dienst-Agenten (service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com) entfernt werden. Ist das 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 roles/cloudbuild.serviceAgent-Rolle mit der in der Fehlermeldung aufgeführten Berechtigung verantwortlich ist.

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. Prüfen Sie die Verzeichnisnamen auf Rechtschreibung und Einheitlichkeit. 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 den eingeschränkten Diensten in Ihrem Perimeter entfernen, den Trigger erstellen und die Pub/Sub API wieder einschränken, 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 das 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 einer externen Ressource fehlgeschlagen, 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 Ressourcen im öffentlichen Internet zuzugreifen, z. B. auf externe Repositories. Wenn Sie einen privaten Pool erstellen oder aktualisieren, klicken Sie das Kästchen an, um Ihrem privaten Pool externe IP-Adressen zuzuweisen. 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, wenn Sie 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 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 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 von Kontingenteinschränkungen in einer bestimmten Region fehlschlägt:

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

Laden Sie das Docker-Image mit crane herunter und laden Sie es dann in das Cloud Build-Docker-Image hoch.

Fügen Sie der Datei „cloudbuild.yaml“ das folgende Snippet hinzu.

...
  # 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 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 ein eigenes Token mit einer benutzerdefinierten Gültigkeitsdauer in eine Datei schreiben und es für Docker-Befehle verwenden.

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

Wenn Sie Builds in einem privaten Pool ausführen, dessen Diensterstellernetzwerk mit Ihrem eigenen VPC-Netzwerk verbunden ist, muss die private Verbindung zwischen diesen beiden Netzwerken intakt bleiben. Wenn Sie die private Verbindung löschen, auf die ein privater Pool angewiesen ist, kann der private Pool nicht mehr verwendet werden. Dies kann dazu führen, dass Builds in der Warteschlange bleiben, bis die Zeitüberschreitung erreicht wird. 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 zwei Monate sind

Ausstehende Builds, die älter als zwei Monate sind, können nicht genehmigt oder abgelehnt werden. Wenn Sie dies versuchen, wird möglicherweise eine Fehlermeldung wie die folgende angezeigt:

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

Versuchen Sie in diesem Fall, einen neuen Build einzureichen.

Nächste Schritte