feat(platform): pin Odoo 18.0 to upstream 20260421 nightly

README.md

@@ -0,0 +1,39 @@
+# odoosky-odoo
+
+Pinned Odoo platform images for OdooSky v3.
+
+## Why this repo exists
+
+Customer instances must pull from a Git-pinned, OdooSky-controlled
+image. The 2026-05-04 incident proved that pulling Docker Hub's
+rolling `odoo:18.0` tag = inheriting whatever Odoo SA's nightly cron
+shipped that morning. Their May 4 build ships a SQL regression that
+breaks every login on every new pod.
+
+This repo is the **source of truth** for which Odoo nightly each
+major is pinned to. The chart `instance-template-v3` reads from
+this list. ArgoCD reconciles. Customer instances always pull a build
+we tested.
+
+## Where the images live
+
+```
+registry.odoosky.cloud/odoosky/docker-mirror/odoo:<pinnedTag>
+```
+
+Same registry path that already mirrors upstream images for BuildKit
+during addon builds. We're now also using it for runtime Odoo.
+
+## How to bump
+
+See `versions.yaml` — the bump policy + smoke checklist live there.
+The shape: smoke first, push to mirror, update versions.yaml, commit.
+
+## What this is NOT
+
+- A build-from-source pipeline. Today we mirror upstream nightlies as
+  exact bytes. Future enhancement: build from source at a pinned commit
+  with our own patches.
+- An automated bump. P5 in the rollout plan adds a Gitea Actions job
+  that auto-builds + auto-smokes new candidates and proposes bumps.
+  Until then, bumps are operator-clicked on lab1.

versions.yaml

@@ -0,0 +1,40 @@
+# odoosky-odoo — pinned Odoo platform images.
+#
+# Source of truth: which upstream Odoo nightly each major is pinned to.
+# Customer instances pull from registry.odoosky.cloud/odoosky/docker-mirror/odoo:<tag>
+# where <tag> matches the entries below.
+#
+# Bumping policy:
+#   1. Pull a candidate upstream nightly to lab1.
+#   2. Smoke it: deploy a fresh test tenant, login, install one demo
+#      addon, check pod logs for SQL/runtime errors.
+#   3. If clean, push it to our mirror under the same date tag.
+#   4. Update this file. Commit. ArgoCD picks up the new chart values
+#      and customer instances pull the new image on next pod restart.
+#   5. If broken, do nothing. Customers stay on the previous pinned
+#      tag until a clean candidate appears.
+#
+# Never use rolling tags (18.0, 17.0, 16.0). They auto-pull the latest
+# nightly and have shipped regressions to every new instance — see the
+# 2026-05-04 incident with res_users_log query (now() - INTERVAL '15
+# minutes' string-quoted, broke every login).
+
+majors:
+  - major: "18.0"
+    pinnedTag: "18.0-20260421"
+    upstreamSource: "docker.io/library/odoo:18.0-20260421"
+    blessedAt: "2026-05-06"
+    blessedBy: "m@havari.me"
+    notes: "Apr 21 nightly. Predates the 2026-05-04 SQL regression."
+
+  # Add 17.0 / 16.0 / 19.0 entries here as we bring them into the
+  # platform. Each entry MUST be tested before commit.
+
+# Smoke checklist (paste into your bump PR description):
+#   [ ] nerdctl pull <upstream>
+#   [ ] nerdctl tag + push to our mirror
+#   [ ] kubectl apply temp tenant on a sandbox cluster
+#   [ ] login as admin → 200
+#   [ ] /web/dataset/call_kw on a basic model → 200, no SQL errors
+#   [ ] install one demo addon → 'Installed' state
+#   [ ] tear down temp tenant