CF Pages Deploy · Astro build automático del workspace

CF Pages Deploy

⚠️ MIGRADO a Hetzner STAGE (02-07-2026, s188 · “palanca 1” anti-Actions): el deploy ya NO corre en GitHub Actions — lo hace el cron cf-pages-deploy del Super-Cron (/opt/cf-pages-deploy/cf-pages-deploy.sh, cada 10 min, debounce: solo construye si origin/main trae commits nuevos). Mismo mecanismo direct-upload con wrangler — NO la Git Integration nativa (footgun s36). El workflow queda disabled como fallback (rollback: gh workflow enable "CF Pages Deploy" + comentar /etc/cron.d/cf-pages-deploy). Motivo: era el mayor consumidor de Actions (~2 min × cada push a main). Trade: el sitio tarda ≤10 min en reflejar un push (antes ~3). Detalle operativo: AUTOMATISMOS.md §3/§4.

Qué hace

Compila el workspace Astro 6 y lo despliega a Cloudflare Pages tras cada push a main. Tiempo típico: ~1 min build + ~30 s propagación (ahora desde Hetzner, cadencia ≤10 min).

Trigger

~~Push a main del repo CreaRackSL-workspace~~ → cron cada 10 min en Hetzner STAGE con debounce por SHA (s188). El debounce coalescea rachas de commits igual que hacía el cancel-in-progress del workflow (memoria reference_github_actions_budget): N pushes en la misma ventana = 1 solo deploy con el último SHA.

Migraciones D1: las aplica el deploy (11-09-2026, s323)

Desde el 11-09-2026 el script aplica las migraciones de migrations/ antes de construir y publicar, con el token CLOUDFLARE_D1_TOKEN (scope D1 Edit) del .env de OPS. Nadie aplica migraciones a mano: wrangler d1 execute --file para una migración queda prohibido (tres incidentes por ese camino: s61, s64 y el 11-09-2026, footgun d1_migrations_untracked).

Pasos del script, en orden: (1) si el commit no toca migrations/, no hace nada; (2) wrangler d1 migrations list --remote; (3) candado: si alguna pendiente lleva un número menor o igual que la última registrada en d1_migrations, el registro está desincronizado → [FAIL] sin migrar ni desplegar, correo por send_maintenance_email y el heartbeat avisa también al no ver [OK] en una hora; (4) migrations apply --remote y, solo si va bien, build y deploy. Migrar antes de publicar evita que el código nuevo pida una tabla que aún no existe (el 11-09 /api/search devolvió 503 un rato por eso).

Si salta el candado: verificar en remoto qué migraciones están aplicadas de verdad (tabla a tabla con sqlite_master, columna a columna con pragma_table_info), registrarlas con scripts/seed-d1-migrations.sql y dejar que el siguiente tick continúe. Fuente de verdad del script: scripts/ops/cf-pages-deploy/cf-pages-deploy.sh (se copia con scp a /opt/cf-pages-deploy/).

Validaciones build-time

Schema Astro de src/content/wiki/: cualquier page con frontmatter inválido rompe el build (footgun s56 · wiki_create_page con sources como strings → ver memoria footguns_wiki_create_page_schema).
TypeScript: en build también re-corre tsc --noEmit implícito (pero el job dedicado en ci.yml lo cubre primero).

Cómo detectar fallo

CI muestra el job rojo. Si rompe por wiki schema, el log apunta a la page malformada. Fix: editar el .md correctamente o eliminar la fila inválida + commit nuevo.

Footgun común

CF Pages tiene un proyecto por entorno. El proyecto de PROD se llama crearacksl-workspace. Si alguien rebautiza el proyecto en el dashboard CF, el workflow falla con 404 — habría que actualizar el projectName en el step cloudflare-pages-action.

Véase también

[[ia-tech—automatismos—metodo—ci-workflows]]
[[ia-tech—inventario-automatismos]]