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