Saltar a contenido

ADR-0005 · El build no depende de la base de datos

  • Estado: aceptado
  • Decisores: hquintero
  • Fecha de la decisión: 2026-08-27

Contexto y problema

El plan del pipeline de despliegue necesitaba responder dónde se construye la imagen. Medido el 27/08/2026: next build fallaba si PostgreSQL no era alcanzable, porque las páginas del sitio heredado del template consultan contenido durante la compilación (generateStaticParams y las páginas estáticas de portada y listado de posts). Eso impedía construir en los servidores de GitHub (ubuntu-latest), que no llegan a la base de Compulandia, y obligaba a pasar DATABASE_URI (con contraseña) y PAYLOAD_SECRET como argumentos de build — visibles con docker history para cualquiera que pueda bajar la imagen.

Opciones consideradas

  1. Quitar la dependencia: el build no toca la base (elegida).
  2. Construir en el runner self-hosted, dentro de la red — acopla build y deploy a la misma máquina y exige proteger los secretos de build con mecanismos extra.
  3. Exponer una base para builds — descartada: credenciales de la red interna en GitHub.

Decisión

Opción 1, verificada el 27/08/2026 con una prueba corta y luego implementada:

  • Los tres generateStaticParams del sitio heredado ([slug], posts/[slug], posts/page/[pageNumber]) toleran la falta de base: devuelven lista vacía y las páginas se generan bajo demanda cuando alguien las visita.
  • La portada y el listado de posts pasan a renderizado bajo demanda (force-dynamic): son las únicas páginas estáticas que consultaban contenido al compilar.
  • El Dockerfile y docker-compose.yml dejan de recibir DATABASE_URI y PAYLOAD_SECRET como argumentos de build; quedan solo como entorno de runtime. El único argumento de build es NEXT_PUBLIC_SERVER_URL, que se inlinea en el bundle (por eso sigue habiendo una imagen por entorno).

El costo es nulo en la práctica: el sitio Next local es herencia del template — el contenido real lo renderiza el storefront (ADR-0001) — así que perder su prerenderizado no resigna nada que alguien consuma.

Consecuencias

Positivas

  • La imagen puede construirse en ubuntu-latest y publicarse en GHCR: el carril de build del pipeline queda idéntico al del storefront.
  • Ningún secreto viaja en la imagen ni en sus metadatos de build (docker history limpio).
  • El build ya no puede fallar ni colgarse por el estado de la base.

Negativas / deuda asumida

  • La portada y el listado de posts del sitio local consultan la base en cada visita (perdieron su caché de 10 minutos). Irrelevante mientras nadie consuma ese sitio; si alguna vez importa, restaurar caché con manejo de errores en vez de volver al prerender.
  • La primera visita a cada página del sitio heredado paga el costo de generarla.
  • El docker compose build en el host ya no necesita el .env completo, pero el runbook debe actualizarse cuando el pipeline reemplace ese procedimiento (fase 3 del plan).