From 7e6ea9d66c80c155b7e64e361685e80deda9eb31 Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Sat, 6 Jun 2026 13:53:54 +0200 Subject: [PATCH] manifests: pin umami to exact image SHA (schema mismatch with v1.38.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Previous PR pinned `ghcr.io/umami-software/umami:postgresql-v1.38.0`. The new pod crashlooped on Prisma: ERROR: relation "event" does not exist Migration name: 02_add_event_data Database error code: 42P01 The 120-day-old working pod's actual image is: ghcr.io/umami-software/umami@sha256:28f263fe06f79ebffa5a6a6e9b... It runs an older umami build whose schema doesn't have the `event` table that the v1 migration `02_add_event_data` operates on. The DB has migrations 10-14 applied (newer than 02 by name) but 02 isn't in its applied set -- likely a schema fork between the line our 120d pod runs and the postgresql-vX.Y.Z line that v1.38.0 advances toward. Pin to the exact SHA that the working pod uses, so pod restarts + ArgoCD syncs both keep producing pods on the same known-good image (cached on the node, no registry pull needed). Renovate also stops chasing the broken upgrade path. Proper fix (deferred): plan a v3.x migration. The version-checker dashboard hint `postgresql-latest → 3.1` suggests umami v3.x dropped the `postgresql-` prefix and is what we'd want long-term. That needs a real DB migration plan since the schema lineage is genuinely different from this image. Co-Authored-By: Claude Opus 4.7 (1M context) --- manifests/umami.yaml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/manifests/umami.yaml b/manifests/umami.yaml index 31fb72b..73f1861 100644 --- a/manifests/umami.yaml +++ b/manifests/umami.yaml @@ -187,7 +187,15 @@ spec: cpu: "50m" containers: - name: umami - image: ghcr.io/umami-software/umami:postgresql-v1.38.0 + # NOTE: pinned to the exact image SHA the working 120d-old pod + # is on. v1.38.0 (the latest postgresql-vX.Y.Z) tries to apply + # migration `02_add_event_data` which requires an `event` table + # that this DB doesn't have -- the DB schema is older than v1 + # numbered migrations expect. Until we plan a proper migration + # (likely to umami v3.x, which is what the dashboard `→ 3.1` + # hint suggests), this stays SHA-pinned so Renovate doesn't + # touch it and pod restarts don't roll the version forward. + image: ghcr.io/umami-software/umami@sha256:28f263fe06f79ebffa5a6a6e9bd33b7a278e9342a88e0bdac812416c9f9e4361 ports: - containerPort: 3000 env: