This bumps PostgreSQL from major 16 to major 17. pgautoupgrade handles the data migration automatically on container startup (vacuum -> reindex -> pg_upgrade -> start PG 17). Verified working in a direct --chaos deploy on the cc-ci server. One major at a time per standing guidance.
cc-ci tests use the SQLite backend (default compose.yml), not PostgreSQL -- so this specific upgrade is not exercised by the test suite directly.
Recommended release command:
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.
## hedgedoc recipe upgrade
| service | image | current | new |
|---------|-------|---------|-----|
| db | pgautoupgrade/pgautoupgrade | 16-alpine | 17-alpine |
**Upstream release notes:**
- pgautoupgrade: 16-alpine → 17-alpine: https://github.com/pgautoupgrade/docker-pgautoupgrade/commits/main (tag-only; PG 17.10 at time of bump)
**Operator Action Required:**
- This bumps PostgreSQL from major 16 to major 17. pgautoupgrade handles the data migration automatically on container startup (vacuum -> reindex -> pg_upgrade -> start PG 17). Verified working in a direct --chaos deploy on the cc-ci server. One major at a time per standing guidance.
- cc-ci tests use the SQLite backend (default compose.yml), not PostgreSQL -- so this specific upgrade is not exercised by the test suite directly.
**Recommended release command:**
```
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
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.
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.
hedgedoc recipe upgrade
Upstream release notes:
Operator Action Required:
Recommended release command:
Tested green on the cc-ci recipe CI server (full suite, cold, against this PR head). NOT merged -- for operator review.
cc @trav @notplants
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.View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.