--suppress-logs nessa versão do gcloud CLI no runner ainda tenta ler
logs no fim e dá exit != 0 quando a SA não tem Viewer no projeto. Build
real do PR #8 deu SUCCESS (image lab-18 em AR), mas a step falhou na
finalização do gcloud.
Com --async, gcloud retorna o build ID logo após enfileirar e sai.
Poll explícito via builds describe (que usa cloudbuild.builds.get,
já em builds.editor). Mata o build no primeiro estado terminal != SUCCESS.
Quota_project sozinho não resolve. Reproduzi local com a SA gitea-cd e
peguei a HTTP 403 raw da Storage API: dois calls bloqueados em sequência:
1. GET /storage/v1/b/_cloudbuild → resolvido com grant de roles/storage.admin
no bucket (storage.buckets.get vinha do projectEditor legacy ACL, que
gitea-cd não é).
2. GET /storage/v1/b?prefix=_cloudbuild&project=corepetro → 403 em
storage.buckets.list. Esse permission é project-scoped (não dá pra
grantar bucket-scoped). Em vez de inflar a SA com storage.admin no
projeto, --gcs-source-staging-dir explícito faz gcloud pular o
auto-detect inteiro e usar o bucket especificado.
E --suppress-logs evita o stream que exige Viewer/Owner no projeto pra
ler Cloud Logging — gitea-cd não tem; o build ainda é aguardado e o
exit code propaga correto.
Validado: build de teste alpine deu SUCCESS na primeira tentativa com
esses dois flags.
`gcloud builds submit` faz uma chamada interna à Service Usage API antes
de uploadar o source pro bucket _cloudbuild. Quando autentica via SA key
(google-github-actions/auth), o credentials file não tem quota_project, e
gcloud cai num default que não é corepetro — a chamada à SU falha com
"serviceusage.services.use forbidden" mesmo com roles/serviceusage.serviceUsageConsumer
concedida no projeto.
Fix: setar billing/quota_project explícito antes do builds submit + env
var CLOUDSDK_BILLING_QUOTA_PROJECT como cinto-suspensório.
