Agrega lo que faltaba para desplegar workloads/docs-portal/ (ya existente sin commitear): deployment/service/ingress + kustomization siguiendo el patrón de workloads/nginx, Applications de workload y gobernanza separadas, y el workflow de Gitea Actions (build+push a Gitea Registry, bump de versión en el manifiesto) siguiendo el mismo patrón que build.yaml/build-medusa.yaml.
1.6 KiB
1.6 KiB
Notas sueltas / aprendizajes
TODO (fase 2+): esto es un scratchpad estructurado, no un playbook — va creciendo con notas cortas a medida que aparecen. Las entradas de abajo son semillas reales extraídas de incidentes ya documentados; expandir cada una con más contexto en fases siguientes.
Qué haría distinto
- Fijar
TUNNEL_TRANSPORT_PROTOCOL=http2desde el día uno, no después de un incidente — QUIC/UDP sobre NAT doméstico fue un problema predecible en retrospectiva. Ver ADR 0003. - Separar siempre "chequeo de disponibilidad" de "migraciones" en init containers distintos, y que el chequeo use el mínimo de parámetros posible (host/puerto/usuario/db) en vez de reusar una URI de conexión pensada para la app. Confirmado como decisión correcta en el incidente de crashloop de Medusa.
Gotchas de Medusa v2
- El Store API (
/store/products, validado porStoreGetProductsParams,.strict()) no aceptacurrency_codenicountry_codepara resolver precios calculados — soloregion_idexplícito. Ver playbook de precios. - El campo
thumbnailde un producto no se autocompleta a partir del arrayimages— hay que setearlo explícito desde el Admin si el frontend lo usa como imagen hero en listados.
TODO
- Notas sobre MinIO / S3 provider.
- Notas sobre el subscriber
revalidate-storefront.tsy sus límites. - Qué automatizaría si volviera a montar este lab desde cero.