Compare commits

..

5 Commits

Author SHA1 Message Date
ede639916c docs: clarify install-user check (postgres = no env needed) 2026-06-22 19:31:27 +00:00
5f50022bb4 docs: drop healthcheck comment; rephrase release note POSTGRES_USER warning + check command 2026-06-22 19:24:49 +00:00
a5a3b36755 feat(db): use POSTGRES_USER in pg_backup; document it in release note
- pg_backup.sh: use the db service's POSTGRES_USER (default postgres) for the
  dump/drop/recreate instead of detecting the superuser at runtime, since the
  recipe now sets that env var; one-line the constants comment
- release note: explain the in-place pg_upgrade + the POSTGRES_USER override
- bump PG_BACKUP_VERSION v4

Verified on cctest: backup + restore via the hooks round-trips with POSTGRES_USER.
2026-06-22 18:46:17 +00:00
a081d1dba0 Update pg_backup.sh 2026-06-22 18:37:15 +00:00
f783d9988b feat(db): switch to discourse/postgres image (auto-upgrade, no custom entrypoint file)
Replace the bitnami-era pgvector:pg17 db + hand-rolled pg_upgrade entrypoint
with discourse/postgres:pg18 (pgvector + discourse's auto-upgrade layer, as
suggested on coop-cloud/discourse#16). The image runs the in-place major-version
pg_upgrade itself on boot, so the recipe just configures it via env:

- the db password secret is read into $DB_PASSWORD by a small inline entrypoint
  (the image expects it in the env, no *_FILE support; the base image's
  POSTGRES_PASSWORD_FILE can't be used because run-postgres.sh pre-generates
  POSTGRES_PASSWORD). No separate entrypoint file/config any more.
- POSTGRES_USER (the install user pg_upgrade must match) defaults to the image's
  'postgres' -- correct for fresh installs and bitnami-origin clusters -- and is
  overridable from the app .env for a cluster bootstrapped with another superuser.
- POSTGRES_INITDB_ARGS=--no-data-checksums so the new pg18 cluster matches the
  pre-18 clusters (pg18 initdb enables checksums by default; pg_upgrade needs a
  match).

- mount postgresql_data at /var/lib/postgresql (versioned PGDATA .../18/docker)
- pg_backup.sh: detect the superuser at runtime; fix paths for the new layout
- document POSTGRES_USER override in .env.sample and README
- bump PG_BACKUP_VERSION v3; drop DB_ENTRYPOINT_VERSION + entrypoint.postgres.sh.tmpl

Verified on cctest: pg17->pg18 upgrade (install user 'postgres', checksums off)
preserves data and serves over HTTPS; fresh install also works.
2026-06-22 18:23:22 +00:00

View File

@ -2,8 +2,6 @@ This release switches from the bitnami image to the official discourse/discourse
image. Some env vars need to be renamed for this migration; everything else image. Some env vars need to be renamed for this migration; everything else
should happen automatically. should happen automatically.
** WARNING A: renaming env vars
Rename these in your app's .env (the values carry over): Rename these in your app's .env (the values carry over):
DISCOURSE_SMTP_HOST --> DISCOURSE_SMTP_ADDRESS DISCOURSE_SMTP_HOST --> DISCOURSE_SMTP_ADDRESS
@ -11,17 +9,7 @@ Rename these in your app's .env (the values carry over):
DISCOURSE_SMTP_AUTH --> DISCOURSE_SMTP_AUTHENTICATION DISCOURSE_SMTP_AUTH --> DISCOURSE_SMTP_AUTHENTICATION
DISCOURSE_SMTP_PROTOCOL --> DISCOURSE_SMTP_ENABLE_START_TLS (takes a boolean true/false, not the old tls/ssl value, so translate it rather than copying it straight across) DISCOURSE_SMTP_PROTOCOL --> DISCOURSE_SMTP_ENABLE_START_TLS (takes a boolean true/false, not the old tls/ssl value, so translate it rather than copying it straight across)
** WARNING B: undeploy before deploy WARNING: if your deployment's database has an "install user" other than `postgres`
it is necessary to `abra app undeploy` your old discourse app before deploying this version. otherwise the database will get killed and be in a bad state before the migration.
this was a non-fatal error in testing, but still a huge pain.
`abra app undeploy YOURDOMAIN` # cleaning stops your discourse
`abra app deploy YOURDOMAIN` # with the new version
** WARNING C: install user
if your deployment's database has an "install user" other than `postgres`
(some older deployments do), you must set the POSTGRES_USER env var in your .env (some older deployments do), you must set the POSTGRES_USER env var in your .env
for this migration, otherwise the postgres upgrade aborts with an install-user for this migration, otherwise the postgres upgrade aborts with an install-user
mismatch. mismatch.