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, können über die Console und die gcloud CLI aufgerufen werden. Google Cloud

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 aufgrund einer fehlenden iam.serviceAccounts.actAs-Berechtigung fehl

Der folgende Fehler wird angezeigt, wenn Sie versuchen, einen Build mit einem verwalteten Dienst wie Cloud Run oder App Engine bereitzustellen:

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

Konfigurieren Sie zur Behebung dieses Fehlers Ihr angegebenes Cloud Build-Dienstkonto oder das Standard-Cloud Build-Dienstkonto so, dass es das Dienstkonto des verwalteten Dienstes imitiert, den Sie für Ihren Build verwenden. Weitere Informationen zu dieser Aufgabe finden Sie unter Identitätsübernahme für Cloud Build-Dienstkonten für verwaltete Dienste konfigurieren.

Weitere Informationen zu Dienstkonten und Berechtigungen finden Sie in den folgenden Themen:

Fehler „Permission denied“ bei der Bereitstellung in Cloud Run Functions

Der folgende Fehler wird angezeigt, wenn Sie versuchen, Cloud Run Functions zu verwenden:

ResponseError: status=[403], code=[Ok], message=[Permission 'cloudfunctions.functions.get' denied]

Weisen Sie zur Behebung dieses Fehlers Ihrem Build-Dienstkonto die Rolle „Cloud Run Functions-Entwickler“ zu.

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

Beim Ausführen eines Build-Triggers wird ein Fehler wie der folgende 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 entweder Ihrem benutzerdefinierten Dienstkonto oder dem Standarddienstkonto die Cloud Build Service Account IAM-Rolle zuweisen.

Fehler beim Senden des Builds aufgrund fehlender Berechtigungen des Dienst-Agents

Wenn der Cloud Build-Dienst-Agent gelöscht wurde oder keine Berechtigungen hat, kann beim Senden 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 ist in diesem Szenario der Cloud Build-Dienst-Agent. Führen Sie die folgenden Schritte aus, um dieses Berechtigungsproblem zu beheben:

  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äststs Von Google verwaltete Dienstkonten anzeigen. Wenn er nicht vorhanden ist, 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 als Nächstes 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 Dienst-Agents verantwortlich war, 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 Berechtigungen vom Dienst-Agent entfernt werden (service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com). Sehen Sie sich in diesem Fall 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 verantwortlich ist, die die in der Fehlermeldung aufgeführte Berechtigung enthält.

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 Schreibweise und Konsistenz Ihrer Verzeichnisnamen. 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. In 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 Abrufen von Branches aus einem privaten Repository: fatal: could not read Username

Der folgende Fehler wird angezeigt, wenn Sie versuchen, einen git pull- oder git fetch-Befehl für einen Remote-Branch aus einem privaten Repository auszuführen:

fatal: could not read Username for '<REMOTE_URL>': No such device or address

Dieser Fehler ist bei privaten Repositories zu erwarten, da der Git-Anmeldeinformations-Helper nach dem ersten Klonen des Repositories absichtlich entfernt wird. Um Remote-Branches aus einem privaten Repository abzurufen, richten Sie Autorisierungsanmeldeinformationen (API-Tokens, SSH-Schlüssel) manuell als Build-Schritt ein. Weitere Informationen finden Sie unter Auf private GitHub-Repositories zugreifen.

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.

Builds schlagen mit der Fehlermeldung „Expired“ fehl und es werden keine Logs angezeigt

Sie lösen einen Build aus oder senden ihn und er schlägt mit dem Fehler „Expired“ fehl. Es werden keine Logs generiert.

Prüfen Sie Folgendes in Ihrer Konfiguration:

  • Sie haben einen niedrigeren Wert für queueTtl konfiguriert (z.B. 20 Sekunden).

    Erhöhen Sie den Wert in Ihrem Schema und führen Sie den Build noch einmal aus. Weitere Informationen finden Sie unter queueTtl

  • Sie haben das Kontingent für gleichzeitige Builds erreicht.

    Sie können über die Seite „Kontingente“ in der Google Cloud Console eine Erhöhung anfordern. Weitere Informationen finden Sie unter Kontingente und Limits.

  • Sie verwenden einen privaten Pool und haben eine nicht standardmäßige Maschine ausgewählt.

    Der Start des Builds kann länger dauern, da möglicherweise auf den Start einer neuen virtuellen Maschine gewartet werden muss. Weitere Informationen finden Sie unter Maschinentypen.

    Sie können versuchen, den Maschinentyp zu ändern.

  • Sie verwenden einen privaten Pool und haben einen IP-Bereich für den Pool angegeben.

    Der physische Bereich der IPs bestimmt die Anzahl der Worker-VMs im Pool und damit das Limit für gleichzeitige Builds, auch wenn es niedriger als das Kontingent für gleichzeitige Builds ist. Builds werden in die Warteschlange gestellt, wenn im Pool keine Worker-VMs verfügbar sind.

    Dies tritt auf, wenn die verfügbaren IP-Adressen im angegebenen Subnetz vollständig genutzt werden und keine Adressen für die Zuweisung zu neuen Cloud Build-Workern vorhanden sind. Erhöhen Sie den Bereich im Subnetz und führen Sie den Build noch einmal aus.

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

Der folgende Fehler wird angezeigt, wenn Sie eine Verbindung zu einer externen Ressource von einem privaten Pool aus herstellen:

 Failed to connect to <external_domain>: Connection timed out

Private Pools verwenden externe IPs, um auf Ressourcen im öffentlichen Internet zuzugreifen, z. B. auf externe Repositories. Wählen Sie beim Erstellen oder Aktualisieren eines privaten Pools das Kästchen aus, um Ihrem privaten Pool externe IPs 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 sie 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 Kontingentbeschränkungen fehl

Der folgende Fehler gibt an, dass ein Build aufgrund von Kontingentbeschrä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 bestimmte Region erhöhen zu lassen.

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

Nach dem Ausführen eines Builds werden in Ihrem Cloud Build-Log 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 zur Behebung des Fehlers das Docker-Image mit Crane herunter und laden Sie es dann in das Cloud Build-Docker-Image.

Fügen Sie der Datei „cloudbuild.yaml“ den folgenden 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/).

Nachdem das Image geladen wurde, sollten die vorhandenen Schritte in „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 Docker-Schritten mit langer Ausführungszeit

Build-Schritte, die einen Docker-Befehl enthalten, der länger als eine Stunde ausgeführt wird (z. B. das Hochladen eines großen Images in Artifact Registry), können mit einem Authentifizierungsfehler fehlschlagen. Cloud Build aktualisiert Authentifizierungstokens stündlich, aber Docker kann diese neuen Tokens möglicherweise nicht abrufen, was zu Authentifizierungsproblemen führt. Sie können Ihr eigenes Token mit einer benutzerdefinierten Lebensdauer in eine Datei schreiben und darauf für Docker-Befehle verweisen.

Builds in der Warteschlange 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 sich ein privater Pool stützt, kann der private Pool beschädigt werden. Dies kann dazu führen, dass Builds in der Warteschlange bleiben, bis sie schließlich eine Zeitüberschreitung verursachen. 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

Sie können ausstehende Builds, die älter als zwei Monate sind, nicht genehmigen oder ablehnen. 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 zu senden.

Privater Pool konnte nicht erstellt werden: Worker-Pool ist nicht mit der Service Networking API verbunden

Sie haben versucht, einen privaten Pool zu erstellen. Sie erhalten jedoch die folgende Fehlermeldung:

Failed to create private pool private-worker-pool: generic::failed_precondition: network "projects/PROJECT_NAME/global/networks/vpc-scmdev-lab-vpc" is not peered to the service networking API; please check your configuration and the documentation for troubleshooting and setting up your pool

Damit Builds auf private Ressourcen von Ihrem Virtual Private Cloud-Netzwerk aus zugreifen können, müssen Sie eine Peering-Verbindung zwischen Ihrem Virtual Private Cloud-Netzwerk und dem Virtual Private Cloud-Netzwerk einrichten, in dem sich private Pools befinden. Eine Anleitung finden Sie unter Private Verbindung zwischen Ihrem VPC-Netzwerk und dem Netzwerk des Diensterstellers einrichten.

Nächste Schritte