feat(commerce-backend): revalidar el storefront al crear/borrar productos

El subscriber revalidate-storefront.ts (PR #9) solo escuchaba product.updated y los eventos de variante, asi que un producto nuevo (product.created) o eliminado (product.deleted) no disparaba revalidateTag: el storefront tardaba hasta el ciclo normal de cache (~60s por pod) en reflejar altas/bajas de catalogo, a diferencia de precio/descripcion/imagenes en productos existentes, que ya viajan por product.updated.
Merge pull request 'chore(gitops): fijar Medusa a v1.0.90 tras carrera de promocion en CI' (#10 ) from fix/medusa-manifest-lagged-race into main
2026-08-13 16:55:16 -05:00 · 2026-08-13 21:41:45 +00:00 · 2026-08-13 16:39:28 -05:00 · 2026-08-13 21:19:17 +00:00
3 changed files with 5 additions and 3 deletions
@@ -36,7 +36,9 @@ export default async function revalidateStorefrontHandler({

 export const config: SubscriberConfig = {
  event: [
+    "product.created",
    "product.updated",
+    "product.deleted",
    "product-variant.updated",
    "product-variant.created",
    "product-variant.deleted",
@@ -52,7 +52,7 @@ spec:
              memory: 64Mi

        - name: migrations
-          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.88
+          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.90
          imagePullPolicy: IfNotPresent
          command:
            - npx
@@ -73,7 +73,7 @@ spec:

      containers:
        - name: medusa
-          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.88
+          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.90
          imagePullPolicy: IfNotPresent
          envFrom:
            - configMapRef:
@@ -16,7 +16,7 @@ spec:
      - name: gitea-registry-secret
      containers:
      - name: web
-        image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.89
+        image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.91
        ports:
        - containerPort: 80
        env:
Author	SHA1	Message	Date
devops	8c52229e71	feat(commerce-backend): revalidar el storefront al crear/borrar productos El subscriber revalidate-storefront.ts (PR #9) solo escuchaba product.updated y los eventos de variante, asi que un producto nuevo (product.created) o eliminado (product.deleted) no disparaba revalidateTag: el storefront tardaba hasta el ciclo normal de cache (~60s por pod) en reflejar altas/bajas de catalogo, a diferencia de precio/descripcion/imagenes en productos existentes, que ya viajan por product.updated.	2026-08-13 16:55:16 -05:00
devops	2d09867f70	Merge pull request 'chore(gitops): fijar Medusa a v1.0.90 tras carrera de promocion en CI' (#10 ) from fix/medusa-manifest-lagged-race into main	2026-08-13 21:41:45 +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	095912d02d	chore: release v1.0.91 [skip ci]	2026-08-13 21:19:17 +00:00