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?
Upgrade: mattermost-lts app 10.11.20 → 11.7.6 (ESR)
Image tag changes
Changes
mattermost/mattermost-team-editionfrom 10.11.20 to 11.7.6 (current ESR / LTS line)pg_backup.shscript with properpg_dump | gzipbackup andDROP DATABASE WITH (FORCE)+ reimport restore (previous inline-label restore was a silent no-op)abra recipe releaseafter merge)Upstream release notes
Recommended release command (operator)
abra recipe release mattermost-lts -x(major bump 2.1.12 → 3.0.0: major app version jump 10.x → 11.x ESR + new backup/restore mechanism)
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
!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.