chore: upgrade mattermost to 11.7.6 #2
Reference in New Issue
Block a user
No description provided.
Delete Branch "upgrade-2.1.11+10.11.19"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
mattermost-lts upgrade — refresh to 11.7.6 ESR (the LTS line)
LTS-line resolution (10.x vs 11.x) — survey was wrong
The orchestrator's 2026-06-26 survey claimed "10.x is LTS, target 10.12.4, 11.x is non-LTS = operator-only". That is incorrect. Verified against Mattermost's official release policy (via endoflife.date/mattermost, data 2026-06-27):
This PR refreshes the 11.7 ESR target from 11.7.5 → 11.7.6 (released 2026-06-25, Low–Medium security patch, no breaking changes / no new migrations).
References:
Image table
mattermost-team-edition:10.11.20mattermost-team-edition:11.7.6(ESR)postgres:15-alpinepostgres:15-alpine(unchanged)Upstream release notes:
What this PR includes (one evolving upgrade PR — extends #2)
chore: upgrade mattermost to 11.7.6— this refresh (11.7.5 → 11.7.6, newest 11.7 ESR patch)chore: upgrade mattermost to 11.7.5 (ESR)— the 10.11 ESR → 11.7 ESR line jumpfix(backup): gzip backup, add restore hook+fix(backup): reimport the postgres dump on restore— the postgres restore fix (raw-PGDATA restore was a silent no-op; nowpg_dump | gzip → backup.sqland the restore hook terminates connections,DROP DATABASE WITH (FORCE), recreates, reimports). Required for the cc-ci restore tier to go green.Postgres: deliberately NOT bumped
postgres:15-alpineis operator-only — a major PG bump (16/17/18) requires an operator-guidedpg_upgradeor dump/restore (a 16-alpine container against pg15 PGDATA crashes on startup; the recipe does NOT use pgautoupgrade). 11.x Mattermost only requires postgres ≥ 14, so 15-alpine is fine.Operator action required
rolestable when upgrading from 10.11.17+); 11.7.6 is safe.Live deploy (dev swarm, step 2b)
Deployed the PR head (image
mattermost-team-edition:11.7.6, postgres15-alpine) underdev-mattermost-lts.ci.commoninternet.netwithabra app deploy --chaos. Converged cleanly: container reportsCurrent version is 11.7.6,Server is listening on [::]:8065, healthhealthy (0 failing), 10.11→11.7 DB migration completed with no errors. Dev deploy torn down (verified no stack/volume leaked).Recommended release command (operator's final publish step — NOT run in this skill)
Major bump: 10.11 ESR → 11.7 ESR line jump + restore bug fix + 11.7.6 security patch. (
abra recipe releaseis NEVER run in the upgrade skill — it publishes; the operator runs it after merging this PR.)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 —
mattermost-lts@5dd708cb❌ failurefull logs · dashboard
chore: upgrade to 2.1.11+10.11.19to fix(backup): add pg_backup.sh restore hook (restore was a no-op)!testme
fix(backup): add pg_backup.sh restore hook (restore was a no-op)to fix(pg-backup): use pg_hba.conf gate for safer restore (matrix-synapse pattern)!testme
CI Assessment: Upgrade correct, restore broken (pre-existing bug)
!testme ran 3 times (runs #159, #160, #161) — all RED on the same test:
test_restore_returns_statefails after backup→restore cycle:relation "ci_marker" does not existRoot cause
This is a pre-existing recipe bug, NOT a regression introduced by the 10.11.18 → 10.11.19 upgrade:
backupbot.backup.path: "/var/lib/postgresql/data/"which backed up the raw PGDATA directory. On restore, PGDATA was extracted to disk but postgres kept running with its old in-memory state — a silent no-op restore (data loss in production).What I tried
I incorporated the pg_backup.sh fix from PR #1 (which adds a proper
backupbot.restore.post-hookusing the matrix-synapse pattern). Both thepg_terminate_backendapproach (run #160) and thepg_hba.confapproach (run #161) fail with the same error.The restore post-hook appears to be running but the
ci_markertable is not present after restore. This may be due to:backupbot.backup.volumes.postgres_data.path: "backup.sql"Recommended operator action
The 3-run testme budget is exhausted. The PR remains open for operator review.
fix(pg-backup): use pg_hba.conf gate for safer restore (matrix-synapse pattern)to chore: upgrade to 2.1.11+10.11.19!testme
🌻 cc-ci —
mattermost-lts@c2acdd07❌ failurefull logs · dashboard
!testme
🌻 cc-ci —
mattermost-lts@9ddfd044❌ failurefull logs · dashboard
!testme
🌻 cc-ci —
mattermost-lts@9ddfd044❌ failurefull logs · dashboard
!testme
🌻 cc-ci —
mattermost-lts@a333e31a✅ passedfull logs · dashboard
chore: upgrade to 2.1.11+10.11.19to fix(backup): gzip backup, add restore hook, bump to 2.1.12!testme
🌻 cc-ci —
mattermost-lts@966c6d61✅ passedfull logs · dashboard
!testme
🌻 cc-ci —
mattermost-lts@966c6d61✅ passedfull logs · dashboard
fix(backup): gzip backup, add restore hook, bump to 2.1.12to chore: upgrade mattermost to 11.7.5 (ESR)!testme
🌻 cc-ci —
mattermost-lts@d5bbffe3❌ failurefull logs · dashboard
chore: upgrade mattermost to 11.7.5 (ESR)to fix(backup): reimport the postgres dump on restore (restore was a no-op)!testme
🌻 cc-ci —
mattermost-lts@24251724✅ passedfull logs · dashboard
!testme
🌻 cc-ci —
mattermost-lts@24251724✅ passedfull logs · dashboard
!testme
🌻 cc-ci —
mattermost-lts@24251724✅ passedfull logs · dashboard
fix(backup): reimport the postgres dump on restore (restore was a no-op)to chore: upgrade mattermost to 11.7.6!testme
🌻 cc-ci —
mattermost-lts@1ca46eda✅ passedfull logs · dashboard
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.