--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.
- Reverte cd.yml pra Cloud Build (gcloud builds submit). Kaniko da PR #5
quebra porque a imagem kaniko:debug não tem /bin/sleep no PATH e o
act-runner usa entrypoint=["/bin/sleep","10800"] no container do job.
- Bump node:18 -> node:20 no stage do webcomponent (Vite >= 5 exige Node 20+).
Pré-requisito pro Cloud Build funcionar: SA gitea-cd precisa de
roles/cloudbuild.builds.editor + roles/serviceusage.serviceUsageConsumer.
O `####` aparecia literal no balão da saudação porque o markdown
processor do bootstrap renderiza headers, mas o estilo destoava
do resto. Usa **negrito** pra destaque visual consistente.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Job 1 (build) roda dentro da imagem gcr.io/kaniko-project/executor:debug
e usa _json_key auth do AR. Job 2 (deploy) é runner default + kubectl
e depende do build via 'needs'.
Step container do act-runner não consegue conectar no docker daemon
(dind sidecar usa tcp://localhost:2375 mas o step roda em network
isolada). Cloud Build resolve sem precisar configurar networking do
runner — bonus: build em VM linux/amd64 sem cross-compile.
Em algumas versões do Gitea Actions, hashFiles avalia para string vazia
mesmo com o arquivo presente, fazendo a job ser marcada como 'skipped'
silenciosamente. O Dockerfile é requisito do CD nesse repo, então a
condicional não agrega segurança.
