OPS70 — Guard de CI: importMap do Payload deve falhar o gate se divergir do config com envs S3 #87

New issue

Closed

opened 2026-08-19 15:45:11 +00:00 by fsolla · 2 comments

fsolla commented

2026-08-19 15:45:11 +00:00

Owner

depends

serializes

priority

model

OPS70

composer-2.5

Plano: —

Contexto

OPS69 (P0, 2026-08-19) foi causado por uma divergência dev/prod do importMap do Payload: o plugin s3Storage é condicional (ativas só com as envs S3_*, que existem em produção), então pnpm generate:importmap rodado sem as envs gera um importMap sem o S3ClientUploadHandler — admin em branco em prod. O fix foi regenerar o importMap com envs dummy e commitar (+2 linhas), mas nada no gate impede que a mesma classe de bug volte:

ci.yml / ci-pr.yml não rodam generate:importmap nem checam o arquivo commitado;
o e2e do admin (tests/e2e/admin.e2e.spec.ts) roda sem S3_* (.env.test sem as envs) — a divergência dev/prod exata;
a única proteção hoje é uma linha de doc no AGENTS.md.

Objetivo

Um guard que falhe o gate (PR e main) quando o importMap commitado divergir do que o config gera com as envs de produção ativadas.

Direção sugerida (reavaliar na execução)

Novo script (ex.: scripts/check-importmap.mjs): roda payload generate:importmap com as 4 S3_* dummy inline (mecânica validada no OPS69 — loadEnvConfig do @next/env não sobrescreve envs do processo; iterateConfig não toca DB), gera para um caminho temporário (ou backup do arquivo atual) e compara com o commitado → exit 1 se divergir.
CI: passo no ci.yml (e ci-pr.yml?) antes da suite — pnpm check:importmap (ex.: pnpm check:importmap script no package.json).
Valores dummy versionados no script (nunca secrets): S3_BUCKET=teqo-media S3_ENDPOINT=http://localhost:3900 S3_ACCESS_KEY_ID=test S3_SECRET_ACCESS_KEY=test.

Aceite

pnpm check:importmap passa com o arquivo atual (pós-OPS69) e falha se alguém regenerar sem as envs.
CI verde com o guard ativo; nenhuma env nova necessária no CI.
Unit test do script (se virar módulo em scripts/lib/) seguindo o padrão dos outros (scripts/lib/cli.mjs etc.).

Fora de escopo

Reavaliar o s3Storage condicional em si (plugin sempre ativo) — decisão de produto/OPS52, não entra aqui.
Mudar o fluxo de geração manual (docs do AGENTS.md já atualizadas no OPS69).

--- id: OPS70 depends: [77] serializes: [] priority: P2 model: composer-2.5 --- Plano: — ## Contexto OPS69 (P0, 2026-08-19) foi causado por uma divergência dev/prod do `importMap` do Payload: o plugin `s3Storage` é condicional (ativas só com as envs `S3_*`, que existem em produção), então `pnpm generate:importmap` rodado **sem** as envs gera um importMap sem o `S3ClientUploadHandler` — admin em branco em prod. O fix foi regenerar o importMap com envs dummy e commitar (+2 linhas), mas **nada no gate impede que a mesma classe de bug volte**: - `ci.yml` / `ci-pr.yml` não rodam `generate:importmap` nem checam o arquivo commitado; - o e2e do admin (`tests/e2e/admin.e2e.spec.ts`) roda sem `S3_*` (`.env.test` sem as envs) — a divergência dev/prod exata; - a única proteção hoje é uma linha de doc no AGENTS.md. ## Objetivo Um guard que falhe o gate (PR e main) quando o `importMap` commitado divergir do que o config gera **com as envs de produção ativadas**. ## Direção sugerida (reavaliar na execução) 1. **Novo script** (ex.: `scripts/check-importmap.mjs`): roda `payload generate:importmap` com as 4 `S3_*` dummy inline (mecânica validada no OPS69 — `loadEnvConfig` do `@next/env` não sobrescreve envs do processo; `iterateConfig` não toca DB), gera para um caminho temporário (ou backup do arquivo atual) e compara com o commitado → exit 1 se divergir. 2. **CI:** passo no `ci.yml` (e `ci-pr.yml`?) antes da suite — `pnpm check:importmap` (ex.: `pnpm check:importmap` script no package.json). 3. Valores dummy versionados no script (nunca secrets): `S3_BUCKET=teqo-media S3_ENDPOINT=http://localhost:3900 S3_ACCESS_KEY_ID=test S3_SECRET_ACCESS_KEY=test`. ## Aceite - `pnpm check:importmap` passa com o arquivo atual (pós-OPS69) e falha se alguém regenerar sem as envs. - CI verde com o guard ativo; nenhuma env nova necessária no CI. - Unit test do script (se virar módulo em `scripts/lib/`) seguindo o padrão dos outros (`scripts/lib/cli.mjs` etc.). ## Fora de escopo - Reavaliar o `s3Storage` condicional em si (plugin sempre ativo) — decisão de produto/OPS52, não entra aqui. - Mudar o fluxo de geração manual (docs do AGENTS.md já atualizadas no OPS69).

fsolla added a new dependency 2026-08-19 15:45:16 +00:00

#77 OPS69 — OPS69 — Admin do Payload abre em branco em produção (importMap sem o handler do storage S3)

fsolla referenced this issue from a commit

2026-08-19 15:52:40 +00:00

ops(OPS69): regenera importMap com o S3ClientUploadHandler (admin abria em branco em prod)

fsolla referenced this issue

2026-08-19 15:52:52 +00:00

OPS69 — importMap com o S3ClientUploadHandler (admin abria em branco em prod) #88

fsolla referenced this issue

2026-08-20 03:41:15 +00:00

OPS73 — Admin do Payload segue em branco em produção — deploy do fix OPS69 (importMap S3) + verificação pós-deploy #114

fsolla commented

2026-08-20 03:42:45 +00:00

Author

Owner

Reforço via OPS73 (#114): o S9 (8d2352c0) foi a 2ª ocorrência da mesma classe — realizou generate:importmap sem as envs S3_* e removeu o handler do importMap, reintroduzindo em produção o erro getFromImportMap: PayloadComponent not found (admin em branco de 2026-08-19 até o deploy do OPS73 em 2026-08-20). A proteção só existe em doc (AGENTS.md). Sugestão de reavaliação de prioridade: P1 (o guard teria falhado ambos os PRs S9/OPS73 e evitado a interrupção do CMS).

Reforço via OPS73 (#114): o S9 (`8d2352c0`) foi a **2ª ocorrência** da mesma classe — realizou `generate:importmap` sem as envs `S3_*` e removeu o handler do importMap, reintroduzindo em produção o erro `getFromImportMap: PayloadComponent not found` (admin em branco de 2026-08-19 até o deploy do OPS73 em 2026-08-20). A proteção só existe em doc (AGENTS.md). Sugestão de reavaliação de prioridade: **P1** (o guard teria falhado ambos os PRs S9/OPS73 e evitado a interrupção do CMS).

fsolla commented

2026-08-21 11:10:03 +00:00

Author

Owner

Tracker migrado para o GitHub — continue em #gh772 (github.com/fsolla/teqo/issues/772). Esta Issue Forgejo está fechada.

fsolla closed this issue

2026-08-21 11:10:04 +00:00