fix: track server appVersion for the migrations image

migrations publishes the same semver as the server, so give it no version
line of its own: leave flyway.image.tag empty and let ister.image fall back
to .Chart.AppVersion (== server.image.tag). Renovate bumping the server now
bumps migrations too, keeping them in lockstep from one source of truth.

ci/release-notes.sh mirrors the same fallback so the migrations row shows the
deployed version instead of a blank cell.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: tijder

CLAUDE.md

@@ -67,14 +67,16 @@ Automatic, and the details matter before you touch `Chart.yaml`:
 - The bump level comes from the commit messages since the last tag: `feat!`/`BREAKING CHANGE` →
   major, `feat` → minor, everything else (including Renovate's `fix(deps):`) → patch. So commit
   messages are functional here, not decoration.
-- The three ister images have **independent version lines** in `values.yaml`; they do not move in
-  lockstep, and `appVersion` speaks only for the server.
+- `server` and `player` have **independent version lines** in `values.yaml`; they do not move in
+  lockstep. `migrations` is the exception: it publishes the same semver as the server, so its
+  `flyway.image.tag` is left **empty** and `ister.image` falls back to `.Chart.AppVersion` (which
+  is `server.image.tag`). Renovate bumping the server therefore bumps migrations too — one source
+  of truth. `ci/release-notes.sh` mirrors that fallback so the migrations row is never blank.
 - Renovate (`renovate.json`), not Dependabot — Dependabot's docker manager cannot tell two images
   in one `values.yaml` apart when they share a tag string (dependabot-core#6891).
 
-`server` and `player` now publish semver tags: `values.yaml` pins both at `1.0.0` and Renovate
-bumps them from there. `migrations` still publishes only `:main`, so its `tag` stays `"main"`
-until it cuts a real release.
+`server` and `player` publish semver tags: `values.yaml` pins both at `1.0.0` and Renovate bumps
+them from there. `migrations` has no `tag` of its own — see the appVersion note above.
 
 ## Conventions
 

ci/release-notes.sh

@@ -37,14 +37,20 @@ print(doc)
 }
 img() { yaml values.yaml "$1"; }
 
+# migrations has no tag of its own: it rides .Chart.AppVersion (== server version), the same
+# fallback ister.image does when flyway.image.tag is empty. Mirror it here so the table shows
+# the version actually deployed rather than a blank cell.
+mig_tag="$(img flyway.image.tag)"
+[ -n "$mig_tag" ] || mig_tag="$(img server.image.tag)"
+
 {
   echo "## ister-chart v${VERSION}"
   echo
   echo "| Component | Image | Version |"
   echo "|---|---|---|"
   echo "| server | \`$(img server.image.repository)\` | $(img server.image.tag) |"
   echo "| website | \`$(img website.image.repository)\` | $(img website.image.tag) |"
-  echo "| migrations | \`$(img flyway.image.repository)\` | $(img flyway.image.tag) |"
+  echo "| migrations | \`$(img flyway.image.repository)\` | ${mig_tag} |"
   echo "| database | \`$(img database.internal.image.repository)\` | $(img database.internal.image.tag) |"
   echo "| typesense | \`$(img typesense.image.repository)\` | $(img typesense.image.tag) |"
   echo "| rabbitmq | subchart \`bitnamicharts/rabbitmq\` | $(python3 -c '

values.yaml

@@ -398,8 +398,11 @@ flyway:
   enabled: true
   image:
     repository: ghcr.io/ister-app/migrations
-    # Versioned independently of the server — see the note on server.image.tag.
-    tag: "main"
+    # migrations publishes the same semver as the server, so it has no version line of its
+    # own: an empty tag makes ister.image fall back to .Chart.AppVersion, which release.yml
+    # derives from server.image.tag. Renovate bumping the server therefore bumps migrations
+    # too — one source of truth, always in lockstep.
+    tag: ""
     digest: ""
     pullPolicy: IfNotPresent
   # Image for the wait-for-db init container; needs pg_isready.