Pular para o conteúdo principal

Adicionar uma nova conta Cloudflare

Cada environment aponta para uma conta Cloudflare via o campo cf_account no deploy.yml. O valor é um prefixo de 2-4 letras maiúsculas que mapeia para um conjunto de org secrets.

Contas atuais:

NomePrefixoSecrets
CactusCTFRONT_CT_CF_ACCOUNT_ID, FRONT_CT_CF_API_TOKEN
BluetecBTFRONT_BT_CF_ACCOUNT_ID, FRONT_BT_CF_API_TOKEN
TesteTSFRONT_TS_CF_ACCOUNT_ID, FRONT_TS_CF_API_TOKEN

Passo a passo​

1 — Criar o API Token na Cloudflare​

No Cloudflare Dashboard da conta nova → My Profile → API Tokens → Create Token (Custom token). O token precisa de todas estas permissions:

PermissionStep que consome
Account > Workers Scripts > Editwrangler deploy
Account > Workers KV Storage > Editprovisioning de KV (quando o cache usa KV)
Zone > Zone > Readresolução do Zone ID para o purge
Zone > Cache Purge > Purgepurge SSR pós-deploy
  • Account Resources: Include → a conta nova.
  • Zone Resources: Include → Specific zone → cada zona apex que será deployada nessa conta. (Pode adicionar mais zonas depois conforme novas brands chegam.)

:::caution Faltou permission = falha silenciosa Falta de Zone:Read ou Cache Purge:Purge resulta em HTTP 401/403 no purge pós-deploy (warning, não erro fatal). Falta de Workers Scripts:Edit quebra o wrangler deploy. :::

2 — Criar as org secrets no GitHub​

GitHub → cactus-agents → Settings → Secrets and variables → Actions. Crie, no mínimo:

  • FRONT_{PREFIX}_CF_ACCOUNT_ID — o Account ID da conta CF
  • FRONT_{PREFIX}_CF_API_TOKEN — o token criado no passo 1

E, conforme os recursos usados pela conta (ver Referência de secrets):

  • FRONT_{PREFIX}_CACHE_PURGE_SECRET — habilita o purge de platform cache
  • FRONT_{PREFIX}_CF_WORKER_KEY — header cf-worker-key (WAF bypass) no purge
  • FRONT_{PREFIX}_R2_ASSETS_ACCESS_KEY / FRONT_{PREFIX}_R2_ASSETS_SECRET — sync de assets para R2 (fallback de chunks)

Em Repository access de cada secret, adicione todos os repos que farão deploy nessa conta.

3 — Registrar o prefixo no reusable workflow​

O reusable front-ops/.github/workflows/deploy.yml mapeia o prefixo para as secrets via env nos steps de resolução. Adicione o novo prefixo seguindo o padrão existente.

Step Resolve CF credentials:

env:
  CF_ACCOUNT: ${{ needs.check.outputs.cf_account }}
  SECRET_CT_ID: ${{ secrets.FRONT_CT_CF_ACCOUNT_ID }}
  SECRET_CT_TOKEN: ${{ secrets.FRONT_CT_CF_API_TOKEN }}
  # ... BT, TS ...
  SECRET_XX_ID: ${{ secrets.FRONT_XX_CF_ACCOUNT_ID }}      # ← novo
  SECRET_XX_TOKEN: ${{ secrets.FRONT_XX_CF_API_TOKEN }}    # ← novo

Faça o mesmo, conforme aplicável, nos steps:

  • Resolve API_BASE_URL and CF_WORKER_KEY → SECRET_XX_WORKER_KEY
  • Resolve R2 S3 API credentials → SECRET_XX_R2_KEY, SECRET_XX_R2_SECRET
  • Resolve cache purge secrets → SECRET_XX_PURGE, SECRET_XX_WORKER_KEY

:::info Por que precisa editar o YAML GitHub Actions não permite indexar secrets.* dinamicamente por nome. O workflow expõe cada secret como uma env var nomeada e resolve por indireção (${!VAR_NAME}). Por isso adicionar uma conta exige adicionar as linhas de env. :::

4 — Usar nos environments​

# environments/<env>/deploy.yml
cf_account: XX

ou como default da brand em brand.yml:

defaults:
  cf_account: XX

Debug rápido de 401 no purge​

TOKEN="<FRONT_{XX}_CF_API_TOKEN>"

# 1. Token válido?
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/user/tokens/verify" | jq

# 2. O token enxerga a zona?
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/zones?name=minha-marca.com" | jq
  • verify retorna 401 → token revogado/expirado → regenerar.
  • verify OK mas zones?name=… retorna "result": [] → zona ausente do Zone Resources.
  • Ambos OK mas POST /purge_cache ainda 401 → token tem Zone:Read mas não Cache Purge:Purge.