Risoluzione degli errori delle build

Questa pagina fornisce strategie di risoluzione dei problemi e soluzioni ad alcuni messaggi di errore comuni che potresti visualizzare durante l'esecuzione di una build.

Hai esaminato i log di build?

Utilizza i log di Logging o di Cloud Storage per ottenere maggiori informazioni sull'errore di build. I log scritti in stdout o stderr vengono visualizzati automaticamente nella Google Cloud console.

Le build manuali non riescono perché l'utente non ha accesso ai log di build

Quando provi a eseguire una build manualmente, viene visualizzato il seguente errore:

AccessDeniedAccess denied. [EMAIL_ADDRESS] does not have storage.objects.get access to the Google Cloud Storage object.

Visualizzi questo errore perché Cloud Build richiede che gli utenti che eseguono build manuali e utilizzano il bucket di log Cloud Storage predefinito dispongano del ruolo IAM Visualizzatore progetto oltre al ruolo Editor Cloud Build. Per risolvere questo errore, puoi procedere in uno dei seguenti modi:

Le build non riescono a causa delle autorizzazioni del account di servizio mancanti

Se il account di servizio che utilizzi per la build non dispone dell'autorizzazione necessaria per eseguire un'attività, visualizzerai un errore simile al seguente:

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

Per risolvere questo errore, concedi l'autorizzazione richiesta all'account di servizio. Utilizza le informazioni nelle pagine seguenti per determinare l'autorizzazione da concedere al account di servizio di build:

Gli errori di build dovuti a autorizzazioni mancanti per i service account di build si verificano comunemente quando si tenta di eseguire il deployment utilizzando Cloud Build.

Errore di autorizzazione negata durante il deployment su Cloud Run Functions

Quando provi a utilizzare le funzioni Cloud Run, viene visualizzato il seguente errore:

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

Per risolvere questo errore, concedi il ruolo Sviluppatore di funzioni Cloud Run al service account di build.

Errore di autorizzazione mancante durante il deployment su Cloud Run Functions

Quando provi a eseguire il deployment sulle funzioni Cloud Run, viene visualizzato un errore simile al seguente:

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

Per risolvere questo errore, concedi il ruolo Utente service account al tuo service account specificato dall'utente o al service account predefinito.

Errore durante il deployment su App Engine

Quando provi a eseguire il deployment su App Engine, viene visualizzato un errore simile al seguente:

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

Per risolvere questo errore, concedi il ruolo Amministratore App Engine al tuo service account specificato dall'utente o al service account predefinito.

Errore durante il deployment su GKE

Quando provi a eseguire il deployment su GKE, viene visualizzato un errore simile al seguente:

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

Per risolvere questo errore, concedi il ruolo Sviluppatore GKE al service account di build.

Errore durante il deployment su Cloud Run

Quando tenti di eseguire il deployment su Cloud Run, viene visualizzato un errore simile al seguente:

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

Visualizzi questo errore perché il account di servizio di build non dispone delle autorizzazioni IAM necessarie per il deployment su Cloud Run. Per informazioni sulla concessione delle autorizzazioni necessarie, consulta Deployment su Cloud Run.

Il trigger di build non riesce a causa dell'autorizzazione cloudbuild.builds.create mancante

Quando esegui un trigger di build, viene visualizzato un errore simile al seguente:

Failed to trigger build: Permission 'cloudbuild.builds.create' denied on resource 'projects/xxxxxxxx' (or it may not exist)

I trigger di build utilizzano un account di servizio per creare una build. Questo errore indica che ilaccount di serviziot non dispone dell'autorizzazione IAM cloudbuild.builds.create, necessaria per account di servizio'esecuzione di un trigger di build. Puoi risolvere questo errore concedendo il ruolo IAM Cloud Build Service Account al tuo service account specificato dall'utente o al service account predefinito.

Invio della build non riuscito a causa di autorizzazioni dell'agente di servizio mancanti

Se l'agente di servizio Cloud Build viene eliminato o non dispone delle autorizzazioni, potrebbe causare il seguente errore durante l'invio di una build.

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.

Il chiamante in questo scenario è l'agente di servizio Cloud Build. Per risolvere questo problema di autorizzazione, segui questi passaggi:

  1. Assicurati che l'agente di servizio Cloud Build esista. Puoi visualizzare l'agente di servizio per un progetto andando alla pagina IAM della console Google Cloud e selezionando la casella di controllo Mostra service account gestiti da Google. Se non è presente, puoi crearlo eseguendo il seguente comando gcloud CLI:

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

  2. Successivamente, concedi il ruolo IAM roles/cloudbuild.serviceAgent all'agente di servizio Cloud Build:

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

Se vuoi verificare quale identità IAM potrebbe essere responsabile del problema di autorizzazione dell'agente di servizio, segui questi passaggi:

  1. Apri Esplora log nella console Google Cloud :

    Vai a Esplora log

  2. Inserisci il seguente testo nel campo della query:

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

  3. Se visualizzi voci di log dopo aver utilizzato questa query, verifica se alcune di queste rimuovono autorizzazioni dall'agente di servizio (service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com). In caso affermativo, esamina protoPayload.authenticationInfo.principalEmail nel log per determinare l'identità IAM responsabile della rimozione dell'autorizzazione o del ruolo roles/cloudbuild.serviceAgent contenente l'autorizzazione elencata nel messaggio di errore.

L'attivatore non riesce a essere eseguito e restituisce l'errore Couldn't read commit

Quando esegui un trigger di build, viene visualizzato il seguente errore:

  Failed to trigger build: Couldn't read commit

Cloud Build restituisce questo messaggio se stai tentando di attivare una build utilizzando un ramo inesistente. Controlla l'ortografia e la coerenza dei nomi delle directory. Per istruzioni sulla configurazione dei trigger, vedi Creare e gestire i trigger di build.

Impossibile creare il trigger Pub/Sub

Quando crei un trigger Pub/Sub, viene visualizzato il seguente errore:

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

Questo errore indica che l'API Pub/Sub è limitata nel tuo progetto. I progetti che limitano l'API Pub/Sub limitano la possibilità di creare sottoscrizioni push. Per risolvere l'errore, puoi rimuovere temporaneamente Pub/Sub dai servizi con limitazioni nel tuo perimetro, creare il trigger e limitare di nuovo l'API Pub/Sub.

Impossibile eseguire il pull o il recupero dei rami da un repository privato a causa dell'errore: fatal: could not read Username

Quando tenti di eseguire un git pull o un git fetch su un ramo remoto da un repository privato, viene visualizzato il seguente errore:

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

Questo errore è previsto nei repository privati, in quanto l'helper delle credenziali Git viene rimosso intenzionalmente dopo la clonazione iniziale del repository. Per recuperare i rami remoti da un repository privato, configura manualmente le credenziali di autorizzazione (token API, chiavi SSH) come passaggio di build. Scopri di più sull'accesso ai repository privati GitHub.

Le build non riescono a causa di un'autorizzazione SSH non valida

Quando esegui una build, viene visualizzato il seguente errore:

Could not parse ssh: [default]: invalid empty ssh-agent socket, make sure SSH_AUTH_SOCK is set

Questo errore indica un problema con l'autorizzazione SSH. Un esempio comune è l'errore di autorizzazione SSH che si verifica quando si accede ai repository privati GitHub con Cloud Build. Per istruzioni sulla configurazione di SSH per GitHub, vedi Accesso ai repository privati GitHub.

Le build non riescono a causa dell'errore No route to host

Quando esegui una build in un pool privato, viene visualizzato il seguente errore o un errore simile:

Unable to connect to the server: dial tcp 192.168.10.XX:<port>: connect: no route to host

Cloud Build esegue i Cloud Builder sulla macchina virtuale nel progetto gestito da Google utilizzando i container Docker. All'interfaccia bridge Docker (e di conseguenza ai container connessi a questa interfaccia) viene assegnato un intervallo IP di 192.168.10.0/24, il che rende impossibile la comunicazione con gli host esterni nella stessa subnet. Quando allochi gli intervalli IP per le risorse nei tuoi progetti durante la configurazione del pool privato, ti consigliamo di selezionare un intervallo al di fuori di 192.168.10.0/24. Per le istruzioni, vedi Configurare l'ambiente per i pool privati.

La connessione alla risorsa esterna non riesce perché non è abilitato alcun IP esterno

Quando ti connetti a una risorsa esterna da un pool privato, viene visualizzato il seguente errore:

 Failed to connect to <external_domain>: Connection timed out

I pool privati utilizzano IP esterni per accedere a risorse su internet pubbliche, come repository esterni. Quando crei o aggiorni un pool privato, seleziona la casella per assegnare IP esterni al pool privato. Per istruzioni sulla creazione o l'aggiornamento dei campi all'interno del tuo pool privato, vedi Creazione e gestione dei pool privati.

Errore di timeout I/O

Quando esegui una build, viene visualizzato il seguente errore:

Timeout - last error: dial tcp IP_ADDRESS: i/o timeout

Questo errore può verificarsi quando la build tenta di accedere alle risorse in una rete privata, ma non riesce. Per impostazione predefinita, le build eseguite tramite Cloud Build possono accedere a risorse private nella rete internet pubblica, ad esempio risorse in un repository o un registro. Tuttavia, le build possono accedere alle risorse in una rete privata solo se utilizzi pool privati e li configuri per accedere alla rete privata. Consulta Utilizzo di Cloud Build in una rete privata.

Errori client 4xx

Questo gruppo di errori indica che la richiesta di build non è andata a buon fine, presumibilmente per colpa dell'utente che ha inviato la richiesta. Alcuni esempi di errori client 4xx sono:

  • **Error**: 404 : Requested entity was not found
  • **Error**: 404 : Trigger not found
  • **Error**: 400 : Failed Precondition
  • **Error**: 403 : Permission denied

Quando visualizzi un errore client 4xx, controlla i log della build per vedere se contengono maggiori informazioni sul motivo dell'errore. Alcune cause comuni degli errori del client includono:

  • La posizione di origine specificata non contiene nulla di nuovo da eseguire il commit e l'albero di lavoro è pulito. In questo caso, controlla la posizione del codice sorgente e prova a eseguire di nuovo la build.
  • Il repository non contiene un file di configurazione della build. In questo caso, carica un file di configurazione della build nel repository ed esegui di nuovo la build.
  • Hai specificato un ID trigger errato.
  • Di recente hai aggiunto un nuovo repository dopo aver installato l'app GitHub e Cloud Build non dispone delle autorizzazioni per accedere al nuovo repository. Se è così, connetti il nuovo repository a Cloud Build.
  • Devi concedere un'altra autorizzazione al account di servizio di build.

La build non riesce a causa di limitazioni della quota

Viene visualizzato il seguente errore, che indica che una build non va a buon fine a causa delle limitazioni di quota in una determinata regione:

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

Contatta l'Assistenza clienti Google Cloud per aumentare le quote per questa regione specifica. Per saperne di più su quote e limiti, consulta Quote e limiti.

Problemi di timeout durante il pull delle immagini dal registro Docker

Dopo l'esecuzione, nel log di Cloud Build vengono visualizzati i seguenti errori di timeout:

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

Per risolvere l'errore, scarica l'immagine Docker utilizzando crane e procedi al caricamento sull'immagine Docker di Cloud Build.

Aggiungi il seguente snippet al file cloudbuild.yaml.

...
  # 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: l'indirizzo del proxy HTTP (ad es. https://proxy.example.com:8888/).

Una volta caricata l'immagine, i passaggi cloudbuild.yaml esistenti dovrebbero funzionare normalmente, ad esempio:

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

Errori Unauthenticated per i passaggi Docker a esecuzione prolungata

I passaggi di build che includono un comando Docker eseguito per più di un'ora (ad esempio il push di un'immagine di grandi dimensioni in Artifact Registry) potrebbero non riuscire a causa di un errore di autenticazione. Cloud Build aggiorna i token di autenticazione ogni ora, ma Docker potrebbe non riuscire a recuperare questi nuovi token, causando problemi di autenticazione. Puoi scrivere il tuo token con una durata personalizzata da archiviare e a cui fare riferimento per i comandi Docker.

Build in coda in un pool privato in peering con una rete VPC

Quando esegui build in un pool privato la cui rete del producer di servizi è in peering con la tua rete VPC, è importante che la connessione privata tra queste due reti rimanga intatta. Se elimini la connessione privata su cui si basava un pool privato, puoi interrompere il funzionamento del pool privato. Questo può essere visualizzato come build che rimangono in coda fino a quando non scadono. Pertanto, se vuoi eliminare una connessione privata, assicurati di eliminare anche tutti i pool privati la cui rete del producer di servizi era connessa alla tua rete VPC utilizzando questa connessione privata.

Tentativo di approvare o rifiutare build in sospeso precedenti a 2 mesi

Non puoi approvare o rifiutare build in sospeso più vecchie di due mesi. Se provi a farlo, potresti visualizzare un messaggio di errore simile al seguente:

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

In questo caso, prova a inviare una nuova build.

Passaggi successivi