ci: add release-to-current multi-service upgrade coverage?

[Sam-Hui-dot]

Hi! I noticed Spliit Cloud's CI covers fresh PostgreSQL migrations, application
tests, integration tests, and Compose validation, but does not currently
exercise a coordinated upgrade from published migrate/api/worker/web images
while retaining an existing PostgreSQL volume.

Would you be open to adding a focused regression check for that path?

I prepared a fork-only candidate that:

• starts the latest immutable rolling release of the migrate, API, worker, and
  web images;
• creates a synthetic three-person group and expense through the real
  anonymous-auth and tRPC application paths;
• builds all four application services from the current checkout;
• converges the same Compose project while retaining the PostgreSQL container
  and named volume;
• verifies the exact expense, payer, split relationships, and calculated
  balances;
• confirms the target migration service reruns successfully with no pending
  migrations.

The GitHub-hosted validation passed here:

https://github.com/Sam-Hui-dot/spliit-cloud/actions/runs/33253615776

The candidate uses a dedicated test Compose file and does not modify
application code or the production Compose topology. UpgradeProof v0.1.0 is
pinned to its immutable Action commit, and the workflow requires no secrets or
production runtime dependencies.

One limitation is that the latest immutable release currently points at the
same product commit as main, so today's run validates the published-image →
current-build release-state convergence and persistent-state invariants, but
does not yet exercise an actual product or migration delta. The check would
begin exercising those deltas automatically as future PRs introduce
state-affecting changes or migrations.

If this kind of coverage fits the project's CI preferences, I can provide the
prepared candidate diff for review and adjust its scope if needed.

[pullfrog]

Summary

A proposal (from an external contributor offering a fork-ready candidate) to add CI coverage for the one upgrade path nothing currently exercises: start the stack from the latest published migrate/api/worker/web images against a fresh PostgreSQL volume, create real data through anonymous-auth + tRPC, then rebuild all four services from the current checkout and re-converge the same Compose project while keeping the Postgres container and volume — asserting the data survives and migrate reruns cleanly with no pending migrations.

The goal behind it is upgrade safety. Today CI only applies Prisma migrations to a fresh DB (bun run prisma-migrate), so a migration or version change that is destructive to, or incompatible with, existing deployed volumes ships with no automated signal. The retained-volume, published-image dimension is the gap being closed.

Feasibility

Feasible and CI-only. It's a new workflow/job plus a dedicated test Compose file; no application code, Dockerfiles, or production Compose topology would change. Docker Compose is already exercised in the existing CI checks job, and the repo already has in-process migration-over-data integration tests (share-fixed-point-migration, split-presets-migration), so this complements rather than duplicates those — it covers the container/volume-level upgrade path the unit-level tests don't.

Caveats to weigh, none of them blocking:

• It only exercises a real schema/product delta on PRs that introduce one: when the checked-out head is ahead of the last published :latest, the current build is migrating a provably-published schema. On unchanged-state PRs it degenerates into a convergence/idempotency recheck (and since today's :latest equals main, the initial run validates convergence only — the author acknowledges this).
• Rebuilding four images adds meaningful CI time on every PR; gating the job to state-affecting changes (Prisma/migration diffs) or to main pushes would keep the cost proportionate.
• The candidate depends on a third-party "UpgradeProof" Action pinned to an immutable commit; a self-contained shell script in the repo would carry less supply-chain surface and keep this reviewable inline.
• Fork PRs must be able to pull the GHCR images read-only, so the packages need to be public-accessible.

Scope

Small-to-medium. A self-contained CI addition (new workflow file + test Compose file + the reviewed candidate diff). It changes CI behavior and per-PR runtime but touches no runtime code, schema, data structures, or permissions, and the existing fresh-migration step stays — it covers a different failure mode than upgrade coverage.

  ^{｜ View workflow run ｜ via Pullfrog ｜ Using openai-compatible/deepseek-v4-flash ｜ 𝕏}

[antonio-ivanovski]

Good suggestion, would appreciate and encourage you to make a PR with setup for this, could be same workflow or separate - whatever you think is suitable and we can iterate on it. As suggestion would also suggest that we make these regression tests versioned, so it is clear for what migration is the test meant to with a configurable setup and configurable expected outcome.