The compose file runs Postgres 18. An install from v1.45 or earlier keeps
its Postgres 16 data in `pgdata`, which 18 cannot open, so a one-shot
`db-upgrade` service moves it on the first start: it starts Postgres 16 on
the old volume inside its own container, streams a dump into 18 in one
transaction, compares every table's row count, gathers planner statistics
and marks the old volume as moved. The app waits for it to succeed.
The old volume is never changed apart from the marker, so the way back is
the previous image and volume lines. A move cut short leaves a "moving"
marker and runs again from scratch; an emptied new volume after a finished
move is refused rather than refilled with the old state.
scripts/compose-db-upgrade-check.sh plays all of it against real
containers from the v1.45.0 compose file, and runs in CI on every change
to the compose file. Pull requests run the integration suite and e2e on
Postgres 18; the nightly integration run keeps 16 covered for installs
that bring their own database.
Every workflow action is pinned to a commit SHA, dependabot auto-merge
is limited to patch and minor updates behind the now-required status
checks on main, and the audit, Trivy and ESLint gates block instead of
warning. The published image finally carries its build SHA and build
timestamp so the version endpoint can prove which commit is running.
The API-token HMAC key fails closed under 32 characters, compose pins
the database minor and denies privilege escalation, and the changelog
drops working-note references in favour of neutral wording.
Informational reachability gate that runs after `Build & Publish
Docker Image` finishes a `main` (or tag) build. Triggered via
`workflow_run` so it always observes the actual completion state of
the build, then:
1. pulls `ghcr.io/${repo}:${tag}` (proves the manifest finished
publishing — the v1.4.14 main run "succeeded" from a wall-clock
POV but the image had to be retagged on the deploy host because
main's manifest never finished pushing; this catches that)
2. boots the container against an ephemeral Postgres service
3. probes `/api/version` (smoke for the build SHA + version slug)
4. probes `/api/health` (smoke for the runtime DB/worker probes)
Every probe runs `continue-on-error: true` — this workflow is
informational, not a deploy gate. A transient registry blip should
surface as a yellow run, not block subsequent builds.
Also wired up `workflow_dispatch` with an `image_tag` input so we
can spot-verify any tag (`v1.4.15`, `v1.4.14`, etc.) on demand
without re-publishing.
Marc-status: filed as proof-of-concept for v1.4.15 phase-C2's
auto-deploy work — Coolify webhook listener can build on top of
the same boot harness.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
dependabot[bot]