Solução de problemas de erros de compilação

Nesta página, fornecemos estratégias de solução de problemas, bem como soluções para algumas mensagens de erro comuns que podem ser exibidas ao executar uma versão.

Você analisou os registros de compilação?

Use os registros de versão do Logging ou do Cloud Storage para ver mais informações sobre o erro de versão. Os registros gravados em stdout ou stderr podem ser visualizados usando o Google Cloud console e a CLI gcloud.

As compilações manuais falham porque o usuário não tem acesso aos registros da versão

Você verá o seguinte erro ao tentar executar uma compilação manualmente:

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

Você vê esse erro porque o Cloud Build requer que os usuários executem versões manuais e usem obucket de registros padrão do Cloud Storage têm o papel de IAM de visualizador do projeto, além do papel de editor do Cloud Build. Para resolver esse erro, siga um destes procedimentos:

As criações falham devido à permissão iam.serviceAccounts.actAs ausente

Você verá o seguinte erro ao tentar implantar uma versão usando um serviço gerenciado, como o Cloud Run ou o App Engine:

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

Para resolver esse erro, configure a conta de serviço especificada do Cloud Build ou a conta de serviço padrão do Cloud Build para representar a conta de serviço do serviço gerenciado que você está usando para a versão. Para mais informações sobre essa tarefa, consulte Configurar a identidade temporária de conta de serviço do Cloud Build para serviços gerenciados.

Para mais informações sobre contas de serviço e permissões, consulte os seguintes tópicos:

Erro de permissão negada ao implantar em funções do Cloud Run

Você verá o seguinte erro ao tentar usar funções do Cloud Run:

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

Para resolver esse erro, conceda o papel de desenvolvedor de funções do Cloud Run à conta de serviço de build.

O gatilho de build falha devido à permissão cloudbuild.builds.create ausente

Você verá algo como o seguinte erro ao executar um gatilho de compilação:

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

Os gatilhos de build usam uma conta de serviço para criar um build. Esse erro indica que a conta de serviço não tem a permissão cloudbuild.builds.create do IAM, que é necessária para que a conta de serviço execute um gatilho de compilação. Para resolver esse erro, conceda o Cloud Build Service Account papel do IAM à conta de serviço especificada pelo usuário ou à conta de serviço padrão.

Falha no envio do build devido à falta de permissões do agente de serviço

Se o agente de serviço do Cloud Build for excluído ou não tiver permissões, ele poderá causar o seguinte erro ao enviar um 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.

O autor da chamada nesse cenário é o agente de serviço do Cloud Build. Para resolver esse problema de permissão, siga estas etapas:

  1. Verifique se o agente de serviço do Cloud Build existe. Para ver o agente de serviço de um projeto, acesse a página IAM no Google Cloud console e marque a caixa de seleção Mostrar contas de serviço gerenciado do Google. Se ele não estiver lá, crie-o executando o seguinte comando da CLI gcloud:

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

  2. Em seguida, conceda o papel do IAM roles/cloudbuild.serviceAgent ao agente de serviço do 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 você quiser verificar qual identidade do IAM foi potencialmente responsável por gerar o problema de permissão do agente de serviço, siga estas etapas:

  1. Abra a Análise de registros no Google Cloud console:

    Acessar a Análise de registros

  2. Digite o seguinte texto no campo de consulta:

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

  3. Se você vir entradas de registro depois de usar essa consulta, verifique se alguma delas está removendo permissões do agente de serviço (service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com). Se sim, consulte o protoPayload.authenticationInfo.principalEmail nesse registro para determinar a identidade do IAM responsável por remover a permissão ou o papel roles/cloudbuild.serviceAgent que contém a permissão listada na mensagem de erro.

O gatilho falha com o erro Couldn't read commit

Você verá o seguinte erro ao executar um gatilho de compilação:

  Failed to trigger build: Couldn't read commit

O Cloud Build retorna essa mensagem se você estiver tentando acionar um build usando uma ramificação que não existe. Revise os nomes dos diretórios para verificar a ortografia e a consistência. Para instruções sobre a configuração do gatilho, consulte Criar e gerenciar gatilhos de build.

Não é possível criar o gatilho do Pub/Sub

Você verá o seguinte erro ao criar um gatilho do Pub/Sub:

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

Esse erro indica que a API Pub/Sub está restrita no seu projeto. Os projetos que restringem a API Pub/Sub limitam a capacidade de criar assinaturas push. Você pode remover temporariamente o Pub/Sub dos serviços restritos no seu perímetro, criar o gatilho e restringir a API Pub/Sub novamente para resolver o erro.

Não é possível extrair ou buscar ramificações de um repositório particular devido ao erro: fatal: could not read Username

Você verá o seguinte erro ao tentar executar um git pull ou git fetch em uma ramificação remota de um repositório particular:

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

Esse erro é esperado em repositórios particulares, já que o auxiliar de credenciais do Git é removido intencionalmente após a clonagem inicial do repositório. Para buscar ramificações remotas de um repositório particular, configure manualmente as credenciais de autorização (tokens de API, chaves SSH) como uma etapa de build. Saiba mais sobre como acessar repositórios particulares do GitHub.

As criações falham devido a uma autorização ssh inválida

Você verá o seguinte erro ao executar uma compilação:

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

Esse erro indica um problema com a autorização SSH. Um exemplo comum é o erro de autorização SSH que ocorre ao acessar repositórios particulares do GitHub com o Cloud Build. Para instruções sobre como configurar o SSH para o GitHub, consulte Como acessar repositórios particulares do GitHub.

Os builds falham devido a um erro No route to host

Você verá o seguinte erro ou semelhante ao executar um build em um pool particular:

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

O Cloud Build executa seus Cloud builders na máquina virtual do projeto gerenciado pelo Google usando os contêineres do Docker. A interface de ponte do Docker (e, consequentemente, os contêineres conectados a essa interface) recebe um intervalo de IP de 192.168.10.0/24, o que impossibilita a comunicação com os hosts externos na mesma sub-rede. Ao alocar intervalos de IP para recursos nos seus projetos durante a configuração do pool particular, recomendamos selecionar um intervalo fora de 192.168.10.0/24. Para instruções, consulte Como configurar o ambiente para pools particulares.

As criações falham com a mensagem de erro: "Expirado" e não mostram registros

Você aciona ou envia um build e ele falha, gerando um erro "Expirado", e nenhum registro é gerado.

Verifique o seguinte na sua configuração:

  • Você configurou um valor queueTtl mais baixo (por exemplo, 20s).

    Aumente o valor no esquema e execute o build novamente. Consulte queueTtl para mais informações.

  • Você atingiu a cota de builds simultâneos.

    Você pode solicitar um aumento na página "Cota" no Google Cloud console. Para mais detalhes, consulte Cotas e limites.

  • Você está usando um pool particular e escolheu a máquina não padrão.

    O build pode levar mais tempo para ser iniciado porque talvez seja necessário aguardar a inicialização de uma nova máquina virtual. Consulte Tipos de máquina para mais informações.

    Você pode tentar mudar o tipo de máquina.

  • Você está usando um pool particular e especificou um intervalo de IP para o pool.

    O intervalo físico de IPs determina o número de VMs de worker no pool e, portanto, o limite de builds simultâneos, mesmo que seja menor que a cota de builds simultâneos. Os builds são enfileirados se não houver VMs de worker disponíveis no pool.

    Isso ocorre quando os endereços IP disponíveis na sub-rede designada são totalmente utilizados, não deixando endereços para alocar novos workers do Cloud Build. Tente aumentar o intervalo na sub-rede e execute o build novamente.

A conexão com o recurso externo falha porque nenhum IP externo está ativado

Você verá o seguinte erro ao se conectar a um recurso externo de um pool particular:

 Failed to connect to <external_domain>: Connection timed out

Os pools particulares usam IPs externos para acessar recursos na Internet pública, como repositórios externos. Ao criar ou atualizar um pool particular, marque a caixa para atribuir IPs externos ao pool particular. Para instruções sobre como criar ou atualizar campos no pool particular, consulte Como criar e gerenciar pools particulares.

Erro de tempo limite de E/S

Você verá o seguinte erro ao executar uma compilação:

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

Esse erro pode ocorrer quando o build tenta acessar recursos em uma rede particular, mas falha. Por padrão, os builds executados pelo Cloud Build podem acessar recursos particulares na Internet pública, como recursos em um repositório ou um registro. No entanto, os builds só podem acessar recursos em uma rede particular se você usar pools particulares e configurá-los para acessar a rede particular. Consulte Como usar o Cloud Build em uma rede particular.

4xx (erros de cliente)

Esse grupo de erros indica que a solicitação de versão não foi bem-sucedida devido a falha do usuário que enviou a solicitação. Veja abaixo alguns exemplos de erros de cliente 4xx:

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

Caso você veja um erro de cliente 4xx, analise os registros da versão para ver se ela contém mais informações sobre o motivo do erro. Veja algumas causas comuns dos erros do cliente:

  • O local de origem especificado não tem nada novo para confirmar, e a árvore de trabalho é limpa. Nesse caso, verifique a localização do código-fonte e tente compilar novamente.
  • Seu repositório não contém um arquivo de configuração de build. Se esse for o caso, faça upload de um arquivo de configuração da versão para seu repositório e execute a compilação novamente.
  • Você especificou um ID de gatilho incorreto.
  • Recentemente, você adicionou um novo repositório depois de instalar o aplicativo GitHub. O Cloud Build não tem permissões para acessar o novo repositório. Se esse for o caso, conecte seu novo repositório ao Cloud Build.
  • Você precisa conceder outra permissão à conta de serviço de build.

O build falha devido a restrições de cota

Você verá o seguinte erro, que indica que um build está falhando devido a restrições de cota em uma região específica:

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

Entre em contato com o Cloud Customer Care para aumentar suas cotas para essa região específica.

Problemas de tempo limite ao extrair imagens do registro do Docker

Você verá os seguintes erros de tempo limite no registro do Cloud Build após executar um build:

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

Para resolver o erro, faça o download da imagem Docker usando crane e carregue a imagem na imagem Docker do Cloud Build.

Adicione o seguinte snippet ao arquivo 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: o endereço do proxy HTTP (por exemplo, https://proxy.example.com:8888/).

Depois que a imagem for carregada, as etapas do cloudbuid.yaml vão funcionar normalmente, por exemplo:

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

Erros Unauthenticated para etapas longas do Docker

As etapas de build que envolvem um comando do Docker executado por mais de uma hora (como enviar uma imagem grande para o Artifact Registry) podem falhar com um erro de autenticação. O Cloud Build atualiza os tokens de autenticação a cada hora, mas o Docker pode não conseguir receber esses novos tokens, resultando em problemas de autenticação. É possível gravar seu próprio token com um tempo de vida personalizado no arquivo e referenciá-lo para comandos do Docker.

Builds enfileirados em um pool particular com peering em uma rede VPC

Ao executar builds em um pool particular que tem a rede do produtor de serviços com peering na sua própria rede VPC, é importante que a conexão particular entre essas duas redes permaneça intacta. Se você excluir a conexão particular em que um pool particular confiava, poderá interromper o pool particular. Isso pode aparecer como builds que permanecem enfileirados até que expirem. Portanto, se você quiser excluir uma conexão particular, também exclua todos os pools particulares cuja rede do produtor de serviços estava conectada à sua própria rede VPC usando essa conexão particular.

Tentativa de aprovar ou rejeitar builds pendentes com mais de dois meses

Não é possível aprovar ou rejeitar builds pendentes com mais de dois meses. Tentar fazer isso pode resultar em uma mensagem de erro como esta:

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

Se isso ocorrer, tente enviar um novo build.

Falha ao criar o pool particular: o pool de workers não tem peering com a API Service Networking

Você tentou criar um pool particular. No entanto, você recebe a seguinte mensagem de erro:

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

Para que as versões acessem recursos particulares da sua rede de nuvem privada virtual, é necessário configurar uma conexão de peering entre sua rede de nuvem privada virtual e a rede de nuvem privada virtual em que os pools privados residem. Para instruções, consulte Como configurar uma conexão particular entre sua rede VPC e a rede do produtor de serviços.

A seguir