mattermost-lts tracks Mattermost's Extended Support Release (ESR/LTS) line — the recipe name is the contract, so we target the newest ESR patch, not the highest version.
ESR verdict (re-checked 2026-10-16 against upstream policy): the current ESR is still 11.7 — Mattermost's release policy states "v11.7 & Desktop App v6.2: Supported until May 15, 2027" and lists "v12.4 … Expected February 2027" as the next ESR. The newest patch on the 11.7 line is 11.7.12 (released 2026-10-08, non-prerelease, on Docker Hub). 12.0.0 is NOT the ESR — it is a major/innovation release (GitHub prerelease=true, rc's through 2026-10-14); the next ESR is v12.4 (~Feb 2027), so 12.0.0 is deliberately not targeted. 11.8/11.9/11.10/11.11 are monthly innovation releases (EOL 2026-09-15 … 2026-12-15, lts:false). 10.11 ESR support ENDED 2026-08-15 (its final patch 10.11.24 sits on a dead line); upstream main still pins 10.11.22, so this PR keeps carrying the required 10.11 → 11.7 ESR move plus the newest 11.7 patch.
This is a re-verification of the existing upgrade PR: it already carried 11.7.12 from 2026-10-09 and no newer ESR patch exists, so the tree is unchanged. A fresh live --chaos deploy on cc-ci exercised the full 10.11.22 → 11.7.12 path: schema migrations ran on boot, server converged, GET /api/v4/system/ping = OK, running version 11.7.12 (build hash cfd9685 matches the v11.7.12 tag).
Image tag table
service
image
old
new
app
mattermost/mattermost-team-edition
10.11.22
11.7.12
postgres
postgres
15-alpine
15-alpine (HELD)
postgres major bumps (16/17/18-alpine) declined — the stack runs a persistent postgres volume and the recipe has no pgautoupgrade, so a major DB bump is a separate, operator-guided pg_upgrade/dump-restore step. 15-alpine floats 15.x patches on re-pull.
Take a DB backup before applying. This PR ships the pg_backup.sh backupbot hooks; the previous raw-PGDATA restore was a silent no-op, fixed here (cherry-picked from the ci/pg-restore PR).
The 10.11 → 11.7 ESR move runs DB schema migrations on boot. Verified live on cc-ci: a --chaos deploy of this branch over a 10.11.22 instance migrated cleanly and served (ping OK, version 11.7.12). The 11.7.11 → 11.7.12 delta is a same-line patch — no new migrations or config.
Do not use 11.7.0–11.7.2 (roles schemeid migration bug from 10.11.17+); 11.7.12 is fine.
postgres stays 15-alpine.
Advisory scan
Window 10.11.22 → 11.7.12: 32 CVEs fixed (deterministic, NVD patched ranges; the adjudication pass's 209 undetermined cases are all nvd:postgres sidecar advisories out of scope for an app-only window, since postgres was HELD — none recorded as unaffected). Additive to the release-note reading; 11.7.12 is an ESR "various bug fixes" patch.
Release (operator, after merge — the version label is intentionally NOT bumped in this PR)
Run once, verbatim, to publish:
abra recipe release mattermost-lts -x
(The 10.11 → 11.7 ESR cross + schema migrations warrant a major bump: computes 3.0.0+11.7.12 from the untouched 2.1.13+10.11.22 label. abra recipe release is the operator's final step — NEVER run in this pipeline.)
Tested green on the cc-ci recipe CI server (full suite, cold, against this PR head). NOT merged — for operator review.
## mattermost-lts: 10.11.22 → 11.7.12 (ESR/LTS)
`mattermost-lts` tracks Mattermost's **Extended Support Release (ESR/LTS)** line — the recipe name is the contract, so we target the newest *ESR* patch, not the highest version.
**ESR verdict (re-checked 2026-10-16 against upstream policy):** the current ESR is **still 11.7** — Mattermost's release policy states *"v11.7 & Desktop App v6.2: Supported until **May 15, 2027**"* and lists *"v12.4 … Expected **February 2027**"* as the **next** ESR. The newest patch on the 11.7 line is **11.7.12** (released 2026-10-08, non-prerelease, on Docker Hub). **12.0.0 is NOT the ESR** — it is a major/innovation release (GitHub `prerelease=true`, rc's through 2026-10-14); the next ESR is v12.4 (~Feb 2027), so 12.0.0 is deliberately *not* targeted. 11.8/11.9/11.10/11.11 are monthly **innovation** releases (EOL 2026-09-15 … 2026-12-15, `lts:false`). **10.11 ESR support ENDED 2026-08-15** (its final patch 10.11.24 sits on a dead line); upstream main still pins 10.11.22, so this PR keeps carrying the required 10.11 → 11.7 ESR move plus the newest 11.7 patch.
This is a re-verification of the existing upgrade PR: it already carried 11.7.12 from 2026-10-09 and no newer ESR patch exists, so the tree is unchanged. A fresh live `--chaos` deploy on cc-ci exercised the full **10.11.22 → 11.7.12** path: schema migrations ran on boot, server converged, `GET /api/v4/system/ping` = OK, running version 11.7.12 (build hash `cfd9685` matches the `v11.7.12` tag).
### Image tag table
| service | image | old | new |
|----------|------------------------------------|----------|--------------|
| app | mattermost/mattermost-team-edition | 10.11.22 | **11.7.12** |
| postgres | postgres | 15-alpine| 15-alpine (HELD) |
postgres major bumps (16/17/18-alpine) declined — the stack runs a persistent postgres volume and the recipe has no pgautoupgrade, so a major DB bump is a separate, operator-guided `pg_upgrade`/dump-restore step. `15-alpine` floats 15.x patches on re-pull.
### Upstream release notes
**Upstream release notes:** app mattermost 10.11.22→11.7.12: https://github.com/mattermost/mattermost/releases/tag/v11.7.12 (ESR changelog: https://docs.mattermost.com/deploy/mattermost-changelog.html)
**ESR/LTS policy:** https://docs.mattermost.com/product-overview/release-policy.html
### Operator action required
- **Take a DB backup before applying.** This PR ships the `pg_backup.sh` backupbot hooks; the previous raw-PGDATA restore was a silent no-op, fixed here (cherry-picked from the `ci/pg-restore` PR).
- The **10.11 → 11.7 ESR move** runs DB schema migrations on boot. Verified live on cc-ci: a `--chaos` deploy of this branch over a 10.11.22 instance migrated cleanly and served (ping OK, version 11.7.12). The 11.7.11 → 11.7.12 delta is a same-line patch — no new migrations or config.
- Do **not** use 11.7.0–11.7.2 (roles `schemeid` migration bug from 10.11.17+); 11.7.12 is fine.
- postgres stays **15-alpine**.
### Advisory scan
Window 10.11.22 → 11.7.12: **32 CVEs** fixed (deterministic, NVD patched ranges; the adjudication pass's 209 undetermined cases are all `nvd:postgres` sidecar advisories out of scope for an app-only window, since postgres was HELD — none recorded as unaffected). Additive to the release-note reading; 11.7.12 is an ESR "various bug fixes" patch.
### Release (operator, after merge — the version label is intentionally NOT bumped in this PR)
Run once, verbatim, to publish:
abra recipe release mattermost-lts -x
(The 10.11 → 11.7 ESR cross + schema migrations warrant a **major** bump: computes `3.0.0+11.7.12` from the untouched `2.1.13+10.11.22` label. `abra recipe release` is the operator's final step — NEVER run in this pipeline.)
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
requested review from trav 2026-06-02 04:40:39 +00:00
autonomic-bot
requested review from notplants 2026-06-02 04:40:39 +00:00
autonomic-bot
changed title from chore: upgrade to 2.1.11+10.11.19 to fix(backup): add pg_backup.sh restore hook (restore was a no-op)2026-06-02 04:53:45 +00:00
autonomic-bot
changed title from 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)2026-06-02 05:04:21 +00:00
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_state fails after backup→restore cycle: relation "ci_marker" does not exist
Root cause
This is a pre-existing recipe bug, NOT a regression introduced by the 10.11.18 → 10.11.19 upgrade:
The image tag bump (10.11.18 → 10.11.19 ESR security patch) is correct and working — install, upgrade, backup, and all functional tests PASS.
The restore mechanism was already broken before this upgrade. The old recipe used 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).
This was already identified in PR #1 (ci/pg-restore) which predates this upgrade PR.
What I tried
I incorporated the pg_backup.sh fix from PR #1 (which adds a proper backupbot.restore.post-hook using the matrix-synapse pattern). Both the pg_terminate_backend approach (run #160) and the pg_hba.conf approach (run #161) fail with the same error.
The restore post-hook appears to be running but the ci_marker table is not present after restore. This may be due to:
The backup.sql file not being captured/restored correctly via backupbot.backup.volumes.postgres_data.path: "backup.sql"
The restore post-hook failing silently (script exits on error, new empty DB created)
A timing issue between mattermost reconnecting and the restore completing
Recommended operator action
Review PR #1 (ci/pg-restore) first — it addresses the same restore issue
Merge PR #1, then rebase/update this upgrade PR on top of it
The upgrade (10.11.18 → 10.11.19 ESR security fix) is safe and correct; the restore fix needs more investigation
The 3-run testme budget is exhausted. The PR remains open for operator review.
## 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_state` fails after backup→restore cycle: `relation "ci_marker" does not exist`
### Root cause
This is a **pre-existing recipe bug**, NOT a regression introduced by the 10.11.18 → 10.11.19 upgrade:
1. The image tag bump (10.11.18 → 10.11.19 ESR security patch) is correct and working — install, upgrade, backup, and all functional tests PASS.
2. The restore mechanism was already broken before this upgrade. The old recipe used `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).
3. This was already identified in **PR #1 (ci/pg-restore)** which predates this upgrade PR.
### What I tried
I incorporated the pg_backup.sh fix from PR #1 (which adds a proper `backupbot.restore.post-hook` using the matrix-synapse pattern). Both the `pg_terminate_backend` approach (run #160) and the `pg_hba.conf` approach (run #161) fail with the same error.
The restore post-hook appears to be running but the `ci_marker` table is not present after restore. This may be due to:
- The backup.sql file not being captured/restored correctly via `backupbot.backup.volumes.postgres_data.path: "backup.sql"`
- The restore post-hook failing silently (script exits on error, new empty DB created)
- A timing issue between mattermost reconnecting and the restore completing
### Recommended operator action
1. Review PR #1 (ci/pg-restore) first — it addresses the same restore issue
2. Merge PR #1, then rebase/update this upgrade PR on top of it
3. The upgrade (10.11.18 → 10.11.19 ESR security fix) is safe and correct; the restore fix needs more investigation
The 3-run testme budget is exhausted. The PR remains open for operator review.
autonomic-bot
changed title from fix(pg-backup): use pg_hba.conf gate for safer restore (matrix-synapse pattern) to chore: upgrade to 2.1.11+10.11.192026-06-05 03:24:46 +00:00
autonomic-bot
changed title from chore: upgrade to 2.1.11+10.11.19 to fix(backup): gzip backup, add restore hook, bump to 2.1.122026-06-12 04:10:51 +00:00
autonomic-bot
changed title from fix(backup): gzip backup, add restore hook, bump to 2.1.12 to chore: upgrade mattermost to 11.7.5 (ESR)2026-06-19 03:36:52 +00:00
autonomic-bot
changed title from chore: upgrade mattermost to 11.7.5 (ESR) to fix(backup): reimport the postgres dump on restore (restore was a no-op)2026-06-19 03:49:29 +00:00
autonomic-bot
changed title from fix(backup): reimport the postgres dump on restore (restore was a no-op) to chore: upgrade mattermost to 11.7.62026-06-29 01:46:08 +00:00
Drone build:#1193 Recipe: mattermost-lts Ref:0474323a4e (upgrade-2.1.11+10.11.19) Image: mattermost/mattermost-team-edition:11.9.0 Verdict: GREEN — full cold suite (install, upgrade, backup, restore, custom) passed against 11.9.0.
Stage recipe-ci: clone ✅, ci ✅ (~160s).
Triggered via the Drone-direct workaround (the ccci-bridge is broken this run — stale gitea-bot swarm secret → HTTP 401; every !testme is silently dropped). A scope-limited GITEA_TOKEN was minted for the runner clone and deleted after. Not merged — for operator review.
⚠️Lifecycle note: 11.9.0 is an innovation release (NOT ESR), EOL 2026-10-15 (~10 weeks). The mattermost-lts recipe has tracked the 11.7 ESR line (supported through 2027-05-15; latest 11.7.8). Operator decides whether to merge 11.9.0 or re-target 11.7.8.
<!-- cc-ci:testme -->
## cc-ci !testme result — GREEN
**Drone build:** [#1193](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1193)
**Recipe:** mattermost-lts
**Ref:** 0474323a4e493e9ec7b6e0144be9c4f1b1149940 (upgrade-2.1.11+10.11.19)
**Image:** mattermost/mattermost-team-edition:11.9.0
**Verdict:** GREEN — full cold suite (install, upgrade, backup, restore, custom) passed against 11.9.0.
Stage `recipe-ci`: clone ✅, ci ✅ (~160s).
Triggered via the Drone-direct workaround (the `ccci-bridge` is broken this run — stale gitea-bot swarm secret → HTTP 401; every `!testme` is silently dropped). A scope-limited GITEA_TOKEN was minted for the runner clone and deleted after. Not merged — for operator review.
⚠️ **Lifecycle note:** 11.9.0 is an innovation release (NOT ESR), EOL 2026-10-15 (~10 weeks). The `mattermost-lts` recipe has tracked the 11.7 ESR line (supported through 2027-05-15; latest 11.7.8). Operator decides whether to merge 11.9.0 or re-target 11.7.8.
autonomic-bot
changed title from chore: upgrade mattermost to 11.9.0 to chore: upgrade mattermost to 11.10.02026-08-07 04:49:43 +00:00
Note: restore fix preserved in this bump (force-push correction)
The initial fast-forward of this bump (a68b7cf) accidentally dropped the pg_backup.sh restore
fix (it was committed on top of upstream main, which has the old inline-label backupbot config
with no restore hook, rather than on the previous PR tip which carried the fix). That caused !testme runs #1220 + #1221 to RED on test_restore_returns_state (restore was a silent no-op — relation "ci_marker" does not exist).
Corrected by committing 156bf91 on top of the previous PR tip 0474323 (11.9.0 + restore
fix), so the tree now has BOTH the pg_backup.sh restore hook AND the 11.10.0 image bump, then
force-pushed to this branch (replacing a68b7cf). The only diff vs 0474323 is the image tag.
Run #1223 GREEN — full cold suite passed, restore test failures=0. The restore fix continues
to work with 11.10.0. (Run #1222 was a transient clone-stage failure — git.autonomic.zone blip, no
artifacts — not a code issue.)
Nothing merged — for operator review. See the PR body for the pre-release + ESR-vs-innovation flags.
## Note: restore fix preserved in this bump (force-push correction)
The initial fast-forward of this bump (`a68b7cf`) accidentally **dropped the `pg_backup.sh` restore
fix** (it was committed on top of upstream `main`, which has the old inline-label backupbot config
with no restore hook, rather than on the previous PR tip which carried the fix). That caused
`!testme` runs #1220 + #1221 to RED on `test_restore_returns_state` (restore was a silent no-op —
`relation "ci_marker" does not exist`).
**Corrected** by committing `156bf91` on top of the previous PR tip `0474323` (11.9.0 + restore
fix), so the tree now has BOTH the `pg_backup.sh` restore hook AND the 11.10.0 image bump, then
force-pushed to this branch (replacing `a68b7cf`). The only diff vs `0474323` is the image tag.
**Run #1223 GREEN** — full cold suite passed, restore test `failures=0`. The restore fix continues
to work with 11.10.0. (Run #1222 was a transient clone-stage failure — git.autonomic.zone blip, no
artifacts — not a code issue.)
Nothing merged — for operator review. See the PR body for the pre-release + ESR-vs-innovation flags.
autonomic-bot
changed title from chore: upgrade mattermost to 11.10.0 to chore: upgrade mattermost to 11.10.0 (+pg_backup restore fix)2026-08-15 20:15:40 +00:00
(summary card unavailable — see the run for details.)full logs · dashboard
<!-- cc-ci:testme -->
🌻 **cc-ci** — `mattermost-lts` @ `7c8ec7c8` ✅ **passed** → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1283
_(summary card unavailable — see the run for details.)_ [full logs](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1283) · [dashboard](https://ci.commoninternet.net/)
autonomic-bot
changed title from chore: upgrade mattermost to 11.10.0 (+pg_backup restore fix) to chore: upgrade mattermost to 11.7.9 (ESR/LTS)2026-08-21 03:39:01 +00:00
(summary card unavailable — see the run for details.)full logs · dashboard
<!-- cc-ci:testme -->
🌻 **cc-ci** — `mattermost-lts` @ `428c3558` ✅ **passed** → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1300
_(summary card unavailable — see the run for details.)_ [full logs](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1300) · [dashboard](https://ci.commoninternet.net/)
autonomic-bot
changed title from chore: upgrade mattermost to 11.7.9 (ESR/LTS) to chore: upgrade mattermost to 11.7.10 (ESR/LTS)2026-08-28 04:09:36 +00:00
autonomic-bot
changed title from chore: upgrade mattermost to 11.7.10 (ESR/LTS) to chore: upgrade mattermost to 11.7.11 (ESR/LTS)2026-09-18 07:49:42 +00:00
autonomic-bot
changed title from chore: upgrade mattermost to 11.7.11 (ESR/LTS) to chore: upgrade mattermost to 11.7.12 (ESR/LTS)2026-10-09 03:09:51 +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.
mattermost-lts: 10.11.22 → 11.7.12 (ESR/LTS)
mattermost-ltstracks Mattermost's Extended Support Release (ESR/LTS) line — the recipe name is the contract, so we target the newest ESR patch, not the highest version.ESR verdict (re-checked 2026-10-16 against upstream policy): the current ESR is still 11.7 — Mattermost's release policy states "v11.7 & Desktop App v6.2: Supported until May 15, 2027" and lists "v12.4 … Expected February 2027" as the next ESR. The newest patch on the 11.7 line is 11.7.12 (released 2026-10-08, non-prerelease, on Docker Hub). 12.0.0 is NOT the ESR — it is a major/innovation release (GitHub
prerelease=true, rc's through 2026-10-14); the next ESR is v12.4 (~Feb 2027), so 12.0.0 is deliberately not targeted. 11.8/11.9/11.10/11.11 are monthly innovation releases (EOL 2026-09-15 … 2026-12-15,lts:false). 10.11 ESR support ENDED 2026-08-15 (its final patch 10.11.24 sits on a dead line); upstream main still pins 10.11.22, so this PR keeps carrying the required 10.11 → 11.7 ESR move plus the newest 11.7 patch.This is a re-verification of the existing upgrade PR: it already carried 11.7.12 from 2026-10-09 and no newer ESR patch exists, so the tree is unchanged. A fresh live
--chaosdeploy on cc-ci exercised the full 10.11.22 → 11.7.12 path: schema migrations ran on boot, server converged,GET /api/v4/system/ping= OK, running version 11.7.12 (build hashcfd9685matches thev11.7.12tag).Image tag table
postgres major bumps (16/17/18-alpine) declined — the stack runs a persistent postgres volume and the recipe has no pgautoupgrade, so a major DB bump is a separate, operator-guided
pg_upgrade/dump-restore step.15-alpinefloats 15.x patches on re-pull.Upstream release notes
Upstream release notes: app mattermost 10.11.22→11.7.12: https://github.com/mattermost/mattermost/releases/tag/v11.7.12 (ESR changelog: https://docs.mattermost.com/deploy/mattermost-changelog.html)
ESR/LTS policy: https://docs.mattermost.com/product-overview/release-policy.html
Operator action required
pg_backup.shbackupbot hooks; the previous raw-PGDATA restore was a silent no-op, fixed here (cherry-picked from theci/pg-restorePR).--chaosdeploy of this branch over a 10.11.22 instance migrated cleanly and served (ping OK, version 11.7.12). The 11.7.11 → 11.7.12 delta is a same-line patch — no new migrations or config.schemeidmigration bug from 10.11.17+); 11.7.12 is fine.Advisory scan
Window 10.11.22 → 11.7.12: 32 CVEs fixed (deterministic, NVD patched ranges; the adjudication pass's 209 undetermined cases are all
nvd:postgressidecar advisories out of scope for an app-only window, since postgres was HELD — none recorded as unaffected). Additive to the release-note reading; 11.7.12 is an ESR "various bug fixes" patch.Release (operator, after merge — the version label is intentionally NOT bumped in this PR)
Run once, verbatim, to publish:
abra recipe release mattermost-lts -x
(The 10.11 → 11.7 ESR cross + schema migrations warrant a major bump: computes
3.0.0+11.7.12from the untouched2.1.13+10.11.22label.abra recipe releaseis the operator's final step — NEVER run in this pipeline.)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
chore: upgrade mattermost to 11.7.6to chore: upgrade mattermost to 11.7.7!testme
🌻 cc-ci —
mattermost-lts@7e121f26✅ passedfull logs · dashboard
chore: upgrade mattermost to 11.7.7to chore: upgrade mattermost to 11.7.8chore: upgrade mattermost to 11.7.8to chore: upgrade mattermost to 11.9.0cc-ci !testme result — GREEN
Drone build: #1193
Recipe: mattermost-lts
Ref:
0474323a4e(upgrade-2.1.11+10.11.19)Image: mattermost/mattermost-team-edition:11.9.0
Verdict: GREEN — full cold suite (install, upgrade, backup, restore, custom) passed against 11.9.0.
Stage
recipe-ci: clone ✅, ci ✅ (~160s).Triggered via the Drone-direct workaround (the
ccci-bridgeis broken this run — stale gitea-bot swarm secret → HTTP 401; every!testmeis silently dropped). A scope-limited GITEA_TOKEN was minted for the runner clone and deleted after. Not merged — for operator review.⚠️ Lifecycle note: 11.9.0 is an innovation release (NOT ESR), EOL 2026-10-15 (~10 weeks). The
mattermost-ltsrecipe has tracked the 11.7 ESR line (supported through 2027-05-15; latest 11.7.8). Operator decides whether to merge 11.9.0 or re-target 11.7.8.chore: upgrade mattermost to 11.9.0to chore: upgrade mattermost to 11.10.0!testme
🌻 cc-ci —
mattermost-lts@a68b7cf7❌ failurefull logs · dashboard
!testme
🌻 cc-ci —
mattermost-lts@a68b7cf7❌ failurefull logs · dashboard
a68b7cf7deto156bf91c94!testme
🌻 cc-ci —
mattermost-lts@156bf91c❌ failure → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1222(summary card unavailable — see the run for details.) full logs · dashboard
!testme
🌻 cc-ci —
mattermost-lts@156bf91c✅ passedfull logs · dashboard
Note: restore fix preserved in this bump (force-push correction)
The initial fast-forward of this bump (
a68b7cf) accidentally dropped thepg_backup.shrestorefix (it was committed on top of upstream
main, which has the old inline-label backupbot configwith no restore hook, rather than on the previous PR tip which carried the fix). That caused
!testmeruns #1220 + #1221 to RED ontest_restore_returns_state(restore was a silent no-op —relation "ci_marker" does not exist).Corrected by committing
156bf91on top of the previous PR tip0474323(11.9.0 + restorefix), so the tree now has BOTH the
pg_backup.shrestore hook AND the 11.10.0 image bump, thenforce-pushed to this branch (replacing
a68b7cf). The only diff vs0474323is the image tag.Run #1223 GREEN — full cold suite passed, restore test
failures=0. The restore fix continuesto work with 11.10.0. (Run #1222 was a transient clone-stage failure — git.autonomic.zone blip, no
artifacts — not a code issue.)
Nothing merged — for operator review. See the PR body for the pre-release + ESR-vs-innovation flags.
chore: upgrade mattermost to 11.10.0to chore: upgrade mattermost to 11.10.0 (+pg_backup restore fix)!testme
156bf91c94to7c8ec7c89b🌻 cc-ci —
mattermost-lts@7c8ec7c8✅ passed → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1277(summary card unavailable — see the run for details.) full logs · dashboard
!testme
🌻 cc-ci —
mattermost-lts@7c8ec7c8✅ passed → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1283(summary card unavailable — see the run for details.) full logs · dashboard
chore: upgrade mattermost to 11.10.0 (+pg_backup restore fix)to chore: upgrade mattermost to 11.7.9 (ESR/LTS)!testme
🌻 cc-ci —
mattermost-lts@428c3558✅ passed → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1300(summary card unavailable — see the run for details.) full logs · dashboard
chore: upgrade mattermost to 11.7.9 (ESR/LTS)to chore: upgrade mattermost to 11.7.10 (ESR/LTS)!testme
cc-ci: failed to start a CI run (see bridge logs).
!testme
🌻 cc-ci —
mattermost-lts@59e8c2c0✅ passed → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1310(summary card unavailable — see the run for details.) full logs · dashboard
!testme
🌻 cc-ci —
mattermost-lts@59e8c2c0✅ passed → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1323(summary card unavailable — see the run for details.) full logs · dashboard
!testme
🌻 cc-ci —
mattermost-lts@59e8c2c0✅ passedfull logs · dashboard
chore: upgrade mattermost to 11.7.10 (ESR/LTS)to chore: upgrade mattermost to 11.7.11 (ESR/LTS)!testme
🌻 cc-ci —
mattermost-lts@5696f0b4✅ passedfull logs · dashboard
!testme
🌻 cc-ci —
mattermost-lts@5696f0b4✅ passedfull logs · dashboard
chore: upgrade mattermost to 11.7.11 (ESR/LTS)to chore: upgrade mattermost to 11.7.12 (ESR/LTS)!testme
🌻 cc-ci —
mattermost-lts@2fbbdb60✅ passedfull logs · dashboard
!testme
🌻 cc-ci —
mattermost-lts@2fbbdb60✅ passedfull logs · dashboard
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.