Extends this PR's db work to pgautoupgrade/pgautoupgrade:18-alpine — the deferred next cycle from 2026-09-11 — carrying the required PG18 volume-mount layout change with it. Supersedes upstream coop-cloud renovate PR #22 (tag-only bump, no mount fix → mount error / empty DB on PG18).
Changes (vs upstream main)
service
image
upstream main
this PR
db
pgautoupgrade/pgautoupgrade
16-alpine
18-alpine
app
quay.io/hedgedoc/hedgedoc
1.12.0
unchanged — 1.12.0 is latest (abra + full quay.io tag list re-checked 2026-09-18)
Commits: 341922a/d9e0da9/8fc323d (16→17, cycle 1) + ad82e0a (17→18 + mount change, cycle 2). The tag bump and mount change are ONE logical change — deploy them together.
Why the volume mount moves with the tag
PG 18 images changed the data-directory layout (docker-library/postgres#1259): PGDATA defaults to /var/lib/postgresql/<MAJOR>/docker and /var/lib/postgresql/data becomes a symlink → keeping the mount at .../data on 18+ yields an OCI mount error or an empty instance instead of an upgraded one (pgautoupgrade README §"Error message when mounting data to /var/lib/postgresql/data on Postgres v18+"). Fix: mount the same postgres volume at /var/lib/postgresql — pgautoupgrade's MOVING_TO_NEW_STRUCTURE entrypoint logic detects the old cluster at the volume root, runs pg_upgrade, and moves the data into the new layout automatically on deploy. No PGDATA env pin needed.
None mandatory — pgautoupgrade upgrades in place on deploy (16 or 17 data → 18, data moved to /var/lib/postgresql/18/docker).
Take a fresh backup first (backupbot labels already on the db service): the upgrade is in-place (pg_upgrade --link, old cluster removed after success).
Do NOT deploy the tag bump without the mount change (and don't merge upstream renovate PR #22 alone).
Live verification on cc-ci (--chaos, 2026-09-18 — sqlite CI doesn't cover the pg override, so this was exercised directly)
Baseline upstream main (16-alpine, old mount): PostgreSQL 16.15, test pad created. Redeployed this PR head on the same volume:
Upgrade to PostgreSQL 18.6 complete. — data auto-moved to /var/lib/postgresql/18/docker
pad content byte-identical; Notes/Revisions/Users 1/1/0 unchanged; app 1/1, HTTP 200 via Traefik
(cycle 1, 2026-09-11, separately verified 16→17: Upgrade to PostgreSQL 17.11 complete., data survived)
advisory scan 2026-09-18: 0 CVEs fixed by this upgrade (6/6 sources live)
Recommended release after merge
abra recipe release hedgedoc -z
Tested green on the cc-ci recipe CI server (full suite, cold, against this PR head). NOT merged — for operator review.
Extends this PR's db work to **pgautoupgrade/pgautoupgrade:18-alpine** — the deferred next cycle from 2026-09-11 — carrying the **required PG18 volume-mount layout change** with it. Supersedes upstream coop-cloud renovate PR #22 (tag-only bump, no mount fix → mount error / empty DB on PG18).
## Changes (vs upstream main)
| service | image | upstream main | this PR |
|---|---|---|---|
| db | pgautoupgrade/pgautoupgrade | 16-alpine | **18-alpine** |
| app | quay.io/hedgedoc/hedgedoc | 1.12.0 | unchanged — 1.12.0 is latest (abra + full quay.io tag list re-checked 2026-09-18) |
Commits: `341922a`/`d9e0da9`/`8fc323d` (16→17, cycle 1) + `ad82e0a` (17→18 + mount change, cycle 2). The tag bump and mount change are ONE logical change — deploy them together.
### Why the volume mount moves with the tag
PG 18 images changed the data-directory layout (docker-library/postgres#1259): PGDATA defaults to `/var/lib/postgresql/<MAJOR>/docker` and `/var/lib/postgresql/data` becomes a symlink → keeping the mount at `.../data` on 18+ yields an OCI mount error or an **empty instance instead of an upgraded one** (pgautoupgrade README §"Error message when mounting data to /var/lib/postgresql/data on Postgres v18+"). Fix: mount the same `postgres` volume at **`/var/lib/postgresql`** — pgautoupgrade's `MOVING_TO_NEW_STRUCTURE` entrypoint logic detects the old cluster at the volume root, runs `pg_upgrade`, and moves the data into the new layout automatically on deploy. No `PGDATA` env pin needed.
**Upstream release notes:** db 17-alpine→18-alpine: https://github.com/pgautoupgrade/docker-pgautoupgrade (README §"Error message when mounting data to /var/lib/postgresql/data on Postgres v18+", issue #164)
**Upstream release notes:** app 1.12.0 (unchanged): https://github.com/hedgedoc/hedgedoc/releases
## Operator action required
- None mandatory — pgautoupgrade upgrades in place on deploy (16 or 17 data → 18, data moved to `/var/lib/postgresql/18/docker`).
- Take a fresh backup first (backupbot labels already on the db service): the upgrade is in-place (`pg_upgrade --link`, old cluster removed after success).
- Do NOT deploy the tag bump without the mount change (and don't merge upstream renovate PR #22 alone).
## Live verification on cc-ci (--chaos, 2026-09-18 — sqlite CI doesn't cover the pg override, so this was exercised directly)
Baseline upstream main (16-alpine, old mount): PostgreSQL 16.15, test pad created. Redeployed this PR head on the same volume:
- `Upgrade to PostgreSQL 18.6 complete.` — data auto-moved to `/var/lib/postgresql/18/docker`
- pad content byte-identical; Notes/Revisions/Users 1/1/0 unchanged; app 1/1, HTTP 200 via Traefik
- (cycle 1, 2026-09-11, separately verified 16→17: `Upgrade to PostgreSQL 17.11 complete.`, data survived)
- advisory scan 2026-09-18: 0 CVEs fixed by this upgrade (6/6 sources live)
## Recommended release after merge
abra recipe release hedgedoc -z
Tested green on the cc-ci recipe CI server (full suite, cold, against this PR head). NOT merged — for operator review.
cc @trav @notplants
autonomic-bot
changed title from chore: upgrade pgautoupgrade from 16-alpine to 17-alpine to chore: upgrade pgautoupgrade to 18-alpine, pin PGDATA=/var/lib/postgresql/data2026-07-03 04:38:53 +00:00
autonomic-bot
changed title from chore: upgrade pgautoupgrade to 18-alpine, pin PGDATA=/var/lib/postgresql/data to chore: merge upstream main (hedgedoc 1.11.1, 3.1.1+1.11.1) into upgrade branch2026-08-04 00:17:32 +00:00
Note: the bridge's !testme webhook is currently silently dropping triggers (stale Gitea-bot swarm secret → HTTP 401), so this CI entry was driven directly via the Drone API (workaround documented in /upgrade-all): triggered a parameterized build on recipe-maintainers/cc-ci with the bridge's exact query-string params (RECIPE=hedgedoc REF=8966fd71262bb097847e1ebb7d698e972e44dc1b PR=3 SRC=recipe-maintainers/hedgedoc), polling the Drone build to completion, and reflecting the verdict back here as a manual Gitea commit-status cc-ci/testme=success + this comment. A scope-limited bot GITEA_TOKEN was minted for the run (so the runner's git clone of the private mirror doesn't reuse the bridge's stale secret) and deleted after.
Branch upgrade-341922a was re-based onto current upstream main (b8f0677, hedgedoc 1.11.1) — the prior tip was a stale branch based on the 3.1.0+1.11.0 publish commit, so --chaos was deploying hedgedoc 1.11.0 and failing readiness at the upgrade tier. The PR diff vs main is now onlycompose.postgresql.yml (db pgautoupgrade/pgautoupgrade 16-alpine → 18-alpine + PGDATA=/var/lib/postgresql/data pin); hedgedoc's app image tracks main's 1.11.1 unchanged.
The pgautoupgrade 16→18 in-place upgrade was also verified directly on the cc-ci swarm via abra app deploy --chaos (postgres override): pg_upgrade 16→18 ran cleanly on first boot (Performing Consistency Checks → Upgrade Complete → Automatic upgrade process finished upgrading the data format to PostgreSQL 18.4), and HedgeDoc 1.11.1 served HTTP 200 on PostgreSQL 18.4.
NOT merged — for operator review.
🌻 **cc-ci** — `hedgedoc` @ `8966fd71262bb097847e1ebb7d698e972e44dc1b` ✅ **passed**
**VERDICT=GREEN** — Drone build [#1178](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1178) succeeded (full cold suite: install, upgrade, backup, restore, custom — all pass; lint pass).
Note: the bridge's `!testme` webhook is currently silently dropping triggers (stale Gitea-bot swarm secret → HTTP 401), so this CI entry was driven **directly via the Drone API** (workaround documented in `/upgrade-all`): triggered a parameterized build on `recipe-maintainers/cc-ci` with the bridge's exact query-string params (`RECIPE=hedgedoc REF=8966fd71262bb097847e1ebb7d698e972e44dc1b PR=3 SRC=recipe-maintainers/hedgedoc`), polling the Drone build to completion, and reflecting the verdict back here as a manual Gitea commit-status `cc-ci/testme=success` + this comment. A scope-limited bot GITEA_TOKEN was minted for the run (so the runner's `git clone` of the private mirror doesn't reuse the bridge's stale secret) and deleted after.
Branch `upgrade-341922a` was re-based onto current upstream main (b8f0677, hedgedoc **1.11.1**) — the prior tip was a stale branch based on the 3.1.0+1.11.0 publish commit, so `--chaos` was deploying hedgedoc 1.11.0 and failing readiness at the upgrade tier. The PR diff vs `main` is now **only** `compose.postgresql.yml` (db `pgautoupgrade/pgautoupgrade` 16-alpine → 18-alpine + `PGDATA=/var/lib/postgresql/data` pin); hedgedoc's app image tracks main's 1.11.1 unchanged.
The pgautoupgrade 16→18 in-place upgrade was also verified directly on the cc-ci swarm via `abra app deploy --chaos` (postgres override): `pg_upgrade` 16→18 ran cleanly on first boot (`Performing Consistency Checks → Upgrade Complete → Automatic upgrade process finished upgrading the data format to PostgreSQL 18.4`), and HedgeDoc 1.11.1 served **HTTP 200** on PostgreSQL 18.4.
NOT merged — for operator review.
autonomic-bot
changed title from chore: merge upstream main (hedgedoc 1.11.1, 3.1.1+1.11.1) into upgrade branch to chore: upgrade pgautoupgrade to 18-alpine2026-08-07 03:42:39 +00:00
autonomic-bot
changed title from chore: upgrade pgautoupgrade to 18-alpine to chore: upgrade db to pgautoupgrade/pgautoupgrade:17-alpine2026-08-14 02:42:11 +00:00
!testme results: RED on all 3 attempts (builds #1264, #1265, #1266) — each failed at the clone step with exit code 128, before the test harness could run. This is a cc-ci infrastructure issue, not a recipe regression (the same clone failure pattern affects multiple recipes in this window).
The upgrade itself is correct:
Direct --chaos deploy on the cc-ci server confirmed the pgautoupgrade migration from PostgreSQL 16 → 17 completes successfully (Upgrade to PostgreSQL 17.10 complete.)
The change is a one-line image tag bump in compose.postgresql.yml (which CI does not exercise — cc-ci tests use the SQLite backend)
Lint passes clean
Operator: review + merge the recipe PR, then run abra recipe release hedgedoc -z to publish. Re-running !testme after the clone infrastructure issue is resolved should yield GREEN.
!testme results: RED on all 3 attempts (builds #1264, #1265, #1266) — each failed at the `clone` step with exit code 128, before the test harness could run. This is a cc-ci infrastructure issue, not a recipe regression (the same clone failure pattern affects multiple recipes in this window).
**The upgrade itself is correct:**
- Direct `--chaos` deploy on the cc-ci server confirmed the pgautoupgrade migration from PostgreSQL 16 → 17 completes successfully (`Upgrade to PostgreSQL 17.10 complete.`)
- The change is a one-line image tag bump in `compose.postgresql.yml` (which CI does not exercise — cc-ci tests use the SQLite backend)
- Lint passes clean
**Operator:** review + merge the recipe PR, then run `abra recipe release hedgedoc -z` to publish. Re-running `!testme` after the clone infrastructure issue is resolved should yield GREEN.
autonomic-bot
changed title from chore: upgrade db to pgautoupgrade/pgautoupgrade:17-alpine to chore: upgrade db to pgautoupgrade/pgautoupgrade:18-alpine2026-08-22 20:37:25 +00:00
(summary card unavailable — see the run for details.)full logs · dashboard
<!-- cc-ci:testme -->
🌻 **cc-ci** — `hedgedoc` @ `d9e0da92` ✅ **passed** → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1302
_(summary card unavailable — see the run for details.)_ [full logs](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1302) · [dashboard](https://ci.commoninternet.net/)
autonomic-bot
changed title from chore: upgrade db to pgautoupgrade/pgautoupgrade:18-alpine to chore: upgrade db to pgautoupgrade/pgautoupgrade:17-alpine2026-09-11 03:09:59 +00:00
autonomic-bot
changed title from chore: upgrade db to pgautoupgrade/pgautoupgrade:17-alpine to chore: upgrade db to pgautoupgrade/pgautoupgrade:18-alpine, move volume mount to /var/lib/postgresql (PG18 data-dir layout)2026-09-18 02:55:04 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Extends this PR's db work to pgautoupgrade/pgautoupgrade:18-alpine — the deferred next cycle from 2026-09-11 — carrying the required PG18 volume-mount layout change with it. Supersedes upstream coop-cloud renovate PR #22 (tag-only bump, no mount fix → mount error / empty DB on PG18).
Changes (vs upstream main)
Commits:
341922a/d9e0da9/8fc323d(16→17, cycle 1) +ad82e0a(17→18 + mount change, cycle 2). The tag bump and mount change are ONE logical change — deploy them together.Why the volume mount moves with the tag
PG 18 images changed the data-directory layout (docker-library/postgres#1259): PGDATA defaults to
/var/lib/postgresql/<MAJOR>/dockerand/var/lib/postgresql/databecomes a symlink → keeping the mount at.../dataon 18+ yields an OCI mount error or an empty instance instead of an upgraded one (pgautoupgrade README §"Error message when mounting data to /var/lib/postgresql/data on Postgres v18+"). Fix: mount the samepostgresvolume at/var/lib/postgresql— pgautoupgrade'sMOVING_TO_NEW_STRUCTUREentrypoint logic detects the old cluster at the volume root, runspg_upgrade, and moves the data into the new layout automatically on deploy. NoPGDATAenv pin needed.Upstream release notes: db 17-alpine→18-alpine: https://github.com/pgautoupgrade/docker-pgautoupgrade (README §"Error message when mounting data to /var/lib/postgresql/data on Postgres v18+", issue #164)
Upstream release notes: app 1.12.0 (unchanged): https://github.com/hedgedoc/hedgedoc/releases
Operator action required
/var/lib/postgresql/18/docker).pg_upgrade --link, old cluster removed after success).Live verification on cc-ci (--chaos, 2026-09-18 — sqlite CI doesn't cover the pg override, so this was exercised directly)
Baseline upstream main (16-alpine, old mount): PostgreSQL 16.15, test pad created. Redeployed this PR head on the same volume:
Upgrade to PostgreSQL 18.6 complete.— data auto-moved to/var/lib/postgresql/18/dockerUpgrade to PostgreSQL 17.11 complete., data survived)Recommended release after merge
abra recipe release hedgedoc -z
Tested green on the cc-ci recipe CI server (full suite, cold, against this PR head). NOT merged — for operator review.
cc @trav @notplants
!testme
🌻 cc-ci —
hedgedoc@341922a2✅ passedfull logs · dashboard
chore: upgrade pgautoupgrade from 16-alpine to 17-alpineto chore: upgrade pgautoupgrade to 18-alpine, pin PGDATA=/var/lib/postgresql/data!testme
🌻 cc-ci —
hedgedoc@c236531d✅ passedfull logs · dashboard
chore: upgrade pgautoupgrade to 18-alpine, pin PGDATA=/var/lib/postgresql/datato chore: merge upstream main (hedgedoc 1.11.1, 3.1.1+1.11.1) into upgrade branch🌻 cc-ci —
hedgedoc@8966fd71262bb097847e1ebb7d698e972e44dc1b✅ passedVERDICT=GREEN — Drone build #1178 succeeded (full cold suite: install, upgrade, backup, restore, custom — all pass; lint pass).
Note: the bridge's
!testmewebhook is currently silently dropping triggers (stale Gitea-bot swarm secret → HTTP 401), so this CI entry was driven directly via the Drone API (workaround documented in/upgrade-all): triggered a parameterized build onrecipe-maintainers/cc-ciwith the bridge's exact query-string params (RECIPE=hedgedoc REF=8966fd71262bb097847e1ebb7d698e972e44dc1b PR=3 SRC=recipe-maintainers/hedgedoc), polling the Drone build to completion, and reflecting the verdict back here as a manual Gitea commit-statuscc-ci/testme=success+ this comment. A scope-limited bot GITEA_TOKEN was minted for the run (so the runner'sgit cloneof the private mirror doesn't reuse the bridge's stale secret) and deleted after.Branch
upgrade-341922awas re-based onto current upstream main (b8f0677, hedgedoc 1.11.1) — the prior tip was a stale branch based on the 3.1.0+1.11.0 publish commit, so--chaoswas deploying hedgedoc 1.11.0 and failing readiness at the upgrade tier. The PR diff vsmainis now onlycompose.postgresql.yml(dbpgautoupgrade/pgautoupgrade16-alpine → 18-alpine +PGDATA=/var/lib/postgresql/datapin); hedgedoc's app image tracks main's 1.11.1 unchanged.The pgautoupgrade 16→18 in-place upgrade was also verified directly on the cc-ci swarm via
abra app deploy --chaos(postgres override):pg_upgrade16→18 ran cleanly on first boot (Performing Consistency Checks → Upgrade Complete → Automatic upgrade process finished upgrading the data format to PostgreSQL 18.4), and HedgeDoc 1.11.1 served HTTP 200 on PostgreSQL 18.4.NOT merged — for operator review.
chore: merge upstream main (hedgedoc 1.11.1, 3.1.1+1.11.1) into upgrade branchto chore: upgrade pgautoupgrade to 18-alpine!testme
🌻 cc-ci —
hedgedoc@8966fd71✅ passedfull logs · dashboard
chore: upgrade pgautoupgrade to 18-alpineto chore: upgrade db to pgautoupgrade/pgautoupgrade:17-alpine!testme
🌻 cc-ci —
hedgedoc@ba679b3e❌ failure → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1264(summary card unavailable — see the run for details.) full logs · dashboard
!testme
🌻 cc-ci —
hedgedoc@ba679b3e❌ failure → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1265(summary card unavailable — see the run for details.) full logs · dashboard
!testme
🌻 cc-ci —
hedgedoc@ba679b3e❌ failure → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1266(summary card unavailable — see the run for details.) full logs · dashboard
!testme results: RED on all 3 attempts (builds #1264, #1265, #1266) — each failed at the
clonestep with exit code 128, before the test harness could run. This is a cc-ci infrastructure issue, not a recipe regression (the same clone failure pattern affects multiple recipes in this window).The upgrade itself is correct:
--chaosdeploy on the cc-ci server confirmed the pgautoupgrade migration from PostgreSQL 16 → 17 completes successfully (Upgrade to PostgreSQL 17.10 complete.)compose.postgresql.yml(which CI does not exercise — cc-ci tests use the SQLite backend)Operator: review + merge the recipe PR, then run
abra recipe release hedgedoc -zto publish. Re-running!testmeafter the clone infrastructure issue is resolved should yield GREEN.chore: upgrade db to pgautoupgrade/pgautoupgrade:17-alpineto chore: upgrade db to pgautoupgrade/pgautoupgrade:18-alpine!testme
🌻 cc-ci —
hedgedoc@d9e0da92✅ passed → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1302(summary card unavailable — see the run for details.) full logs · dashboard
chore: upgrade db to pgautoupgrade/pgautoupgrade:18-alpineto chore: upgrade db to pgautoupgrade/pgautoupgrade:17-alpine!testme
🌻 cc-ci —
hedgedoc@8fc323d4✅ passedfull logs · dashboard
chore: upgrade db to pgautoupgrade/pgautoupgrade:17-alpineto chore: upgrade db to pgautoupgrade/pgautoupgrade:18-alpine, move volume mount to /var/lib/postgresql (PG18 data-dir layout)!testme
🌻 cc-ci —
hedgedoc@7a7d4340✅ passedfull logs · dashboard
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.