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:

• 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 bei der Bereitstellung 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

Weisen Sie dem Cloud Build-Dienstkonto die Rolle „Dienstkontonutzer“ zu, um diesen Fehler zu beheben.

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.

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 weist darauf hin, dass dem Cloud Build-Dienstkonto die IAM-Berechtigung cloudbuild.builds.create fehlt. Diese ist erforderlich, damit das Dienstkonto einen Build-Trigger ausführen kann. 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.

Trigger schlägt mit Couldn't read commit Fehler 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 Zweig auszulösen. Prüfen Sie die Verzeichnisnamen auf Rechtschreibung und Konsistenz. 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 weist darauf hin, dass die Pub/Sub API in Ihrem Projekt eingeschränkt ist. Projekte, die die Pub/Sub API einschränken, schränken die Möglichkeit zum Erstellen von Push-Abos ein. Sie können Pub/Sub vorübergehend aus eingeschränkten Diensten in Ihrem Perimeter entfernen, den Trigger erstellen und die Pub/Sub API noch einmal 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 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

Wenn Sie eine Verbindung zu einer externen Ressource von einem privaten Pool aus 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. externe Repositories. Klicken Sie beim Erstellen oder Aktualisieren eines privaten Pools 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 jedoch 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 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 dem Dienstkonto eine weitere Berechtigung erteilen.

Build schlägt aufgrund von Kontingentbeschränkungen fehl

Der folgende Fehler zeigt 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 Cloud Customer Care, um Ihre Kontingente für diese Region zu erhöhen. Weitere Informationen zu Kontingenten und Limits finden Sie unter Kontingente und Limits.

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

Nach einer Ausführung 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

Um den Fehler zu beheben, laden Sie das Docker-Image mit crane herunter und laden Sie es anschließend 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 cloudbuid.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 andauernden Docker-Schritten

Build-Schritte mit einem Docker-Befehl, der länger als eine Stunde ausgeführt wird (z. B. das Hochladen eines großen Images in Artifact Registry), schlagen möglicherweise mit einem Authentifizierungsfehler fehl. Cloud Build aktualisiert die 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 für Docker-Befehle darauf verweisen.

Achtung: Die Verwendung eines Tokens mit langer Lebensdauer oder eines Tokens, das nicht abläuft, kann das Risiko nicht autorisierter Zugriffe auf Ihre Softwarelieferkette erhöhen. Legen Sie bei Verwendung eines benutzerdefinierten Tokens die kürzestmögliche Lebensdauer für die Ausführung der Aufgabe fest.

Nächste Schritte

• Build-Logs verwalten