11 Commits

Include renames

Author	SHA1	Message	Date
gitea-actions	130177a9f2	chore(gitops): deploy Medusa v1.0.92 [skip ci]	2026-08-13 22:08:17 +00:00
devops	6a0e9965a9	chore(gitops): fijar Medusa a v1.0.90 tras carrera de promocion en CI ... El pipeline build-medusa.yaml (run #90) construyo y publico ecommerce-medusa:v1.0.90 con exito, pero su paso "Actualizar manifiesto Medusa" quedo skipped: el chequeo de promocion segura comparo github.sha contra origin/main y encontro que el commit "chore: release v1.0.91" del frontend ya habia cambiado el HEAD, asi que se abstuvo de sobrescribirlo. medusa.yaml se quedo en v1.0.88, sin el subscriber revalidate-storefront agregado en el PR #9. Bump manual del tag en ambos containers (migrations y medusa) para que Argo CD despliegue la imagen que ya esta en el registry.	2026-08-13 16:39:28 -05:00
devops	d1a4a84d24	feat(ecommerce): revalidar el storefront al instante tras editar precios ... Antes el precio actualizado en Medusa tardaba hasta ~60s (o más, con varias réplicas del frontend sin cache handler compartido) en verse en el front, por el revalidate:60 del fetch a /store/products. Ahora: - Nueva ruta app/api/revalidate en el storefront que llama a revalidateTag("medusa-products") al recibir un POST autenticado con el header x-revalidate-secret. - Nuevo subscriber en el backend Medusa (product.updated, product-variant.updated/created/deleted) que llama a esa ruta usando STOREFRONT_URL (ya existe en commerce-config) y un REVALIDATE_SECRET compartido entre ambos servicios. - secrets.template.yaml documenta la nueva clave REVALIDATE_SECRET en commerce-secrets y commerce-storefront (mismo valor en ambos). Requiere reaplicar commerce-secrets y commerce-storefront con el script actualizado en el repo scripts (fix/revalidate-secret-scripts) para que el REVALIDATE_SECRET exista en el cluster.	2026-08-13 16:02:49 -05:00
gitea-actions	77bf6089fb	chore(gitops): deploy Medusa v1.0.88 [skip ci]	2026-08-13 05:01:13 +00:00
devops	e9c93bfb82	fix(medusa): usar flags explicitos en pg_isready en vez de DATABASE_URL crudo ... El init container wait-for-postgres pasaba $DATABASE_URL completo a pg_isready. Al agregarle ?sslmode=disable (via create-commerce-secrets.sh), pg_isready fallaba con "no attempt" (exit 3, conninfo invalida para su parser de URI) y el pod quedaba atascado en Init indefinidamente, sin llegar nunca al CrashLoopBackOff visible. Postgres, DNS, Endpoints y NetworkPolicy estaban sanos; el fallo era puramente del parseo de la URI. Se reemplaza por -h/-p/-U/-d explicitos (host y puerto fijos del Service, usuario y db ya disponibles via envFrom), asi el init container queda inmune a query params futuros en DATABASE_URL.	2026-08-10 00:27:10 -05:00
devops	7a83ed61b9	fix(medusa): forzar podAffinity con commerce-postgres para evitar blackhole MTU cross-node ... Diagnostico: pg_isready y el cliente pg de Medusa fallan de forma consistente (100%, 186/186 intentos) cuando el pod queda agendado en un nodo distinto al de commerce-postgres-0. TCP handshake (nc/ping) funciona cruzando nodos, pero el primer paquete de datos real de la sesion nunca llega - blackhole de PMTU Discovery entre los nodos del cluster k3d (flannel VXLAN / MTU del bridge Docker subyacente). Se agrega podAffinity requiredDuringSchedulingIgnoredDuringExecution (no nodeSelector fijo, mantiene portabilidad) para que medusa-deploy siempre comparta nodo con commerce-postgres-0 y evite cruzar el blackhole. Es un workaround, no el fix de raiz: documentado en docs/known-issues.md junto con el TODO de ajustar el MTU del cluster a 1400.	2026-08-09 02:34:15 -05:00
devops	f4ad14028e	fix(medusa): agregar initContainer wait-for-postgres para evitar CrashLoopBackOff por fallo transitorio de red en arranque	2026-08-09 01:29:43 -05:00
gitea-actions	7066f2d871	chore(gitops): deploy Medusa v1.0.85 [skip ci]	2026-08-02 07:07:12 +00:00
devops	7f222b118c	chore(commerce): restore MinIO manifest permissions [skip ci]	2026-08-01 00:56:05 -05:00
devops	c865063f24	fix(commerce): use published MinIO image and rebuild Medusa	2026-08-01 00:49:49 -05:00
devops	aa857bc2ae	fase 1	2026-07-31 23:27:01 -05:00