Deploy y patches

Flujo de deploy

git push main → CI GitHub Actions → astro build → wrangler deploy → Cloudflare Workers.

No hay staging — producción directa. Usar D1 Time Travel como red de seguridad antes de cambios de esquema.

Protocolo post-deploy obligatorio

Purgar siempre después de cambios de assets

Después de cualquier deploy que cambie hashes de assets estáticos (upgrade de framework, bundler, Tailwind…):

1. Cloudflare Dashboard → tuperiodico.soy → Caching → Purge Everything
2. Purgar KV cache: wrangler kv key delete --all --binding TPS_CACHE

La edge cache CDN y la KV cache son capas distintas. Purgar una no purga la otra. El deploy de Workers no purga automáticamente la CDN.

Descubierto el 26/06/2026: artículos aparecían sin estilos porque la CDN servía HTML con hashes de Astro 6 que ya no existían en el bundle de Astro 7.

Patches activos

package.json#pnpm.patchedDependencies — usar siempre npx pnpm@9.15.0 (no el pnpm global del sistema).

Patch	Archivo modificado	Qué hace
emdash@0.23.0	dist/astro/middleware.mjs	Elimina campos de sistema (id, slug, status…) antes de validateContentData para evitar error unknown field on collection al guardar contenido
@emdash-cms/cloudflare@0.23.0	dist/auth/index.mjs	Elimina console.log("[cf-access] Identity from Access: …") que filtraría email/grupos del usuario en Workers logs

Recrear patches en cada bump de versión

Los hashes de dist/ cambian en cada versión — el .patch viejo no aplica.

# 1. Iniciar edición
npx pnpm@9.15.0 patch emdash@X.Y.Z

# 2. Editar el archivo en la ruta que devuelve el comando

# 3. Guardar patch
npx pnpm@9.15.0 patch-commit '/ruta/devuelta/por/patch'

Repetir para @emdash-cms/cloudflare@X.Y.Z.

Gestión de pnpm

El repo fija "packageManager": "pnpm@9.15.0" en el package.json raíz.

patchedDependencies se lee de package.json#pnpm en pnpm 9.x pero de pnpm-workspace.yaml en pnpm 11.x. Mezclar versiones hace que un patch deje de aplicarse sin error visible.

Migraciones D1

Las migraciones de EmDash se aplican automáticamente en el primer arranque del Worker tras el deploy. Para migraciones destructivas (como la 040 que reconstruye tablas enteras), verificar antes contra un snapshot de producción:

# Exportar tabla individual (D1 Export falla con FTS5)
wrangler d1 export lemma-db --remote --table _emdash_bylines --output snapshot.sql

EmDash — historial de versiones en producción

Fecha	Versión	Notas
≤ 14/06/2026	0.12.0	Versión inicial en producción
26/06/2026	0.22.0	Upgrade Astro 6→7, migraciones 040-044
26/06/2026	0.23.0	Performance cold start, fix Cache-Control editor