Upgrade: lasuite/drive v0.25.2 → v0.26.0 (extending this PR)
Extends the existing upgrade branch rather than opening a second PR. This adds the v0.26.0
app bump on top of the work already here (drive v0.25.3 + redis 8.10.3 + collabora 26.04.5.2.1 +
onlyoffice 10.0.2.1), so the PR tree now deploys drive v0.26.0 with those sidecars.
Drive v0.26.0 is a feature minor (upload denylist, share-link expiry/password, folder
restrictions, admin item-tree browse, WOPI logging). No declared breaking change and no new required env. Django migrations run automatically on backend start.
⚠ RESTRICT_UPLOAD_FILE_TYPE semantics changed: it was a boolean, now an enum off | allowlist | denylist, and any other value stops backend startup. This recipe does
not set it (defaults to allowlist), so a stock deploy is fine — but a deployer who set RESTRICT_UPLOAD_FILE_TYPE=true|false in their .env must change it before deploying v0.26.0.
New optional env (defaults safe, not added): FILE_MIMETYPE_DENIED, FILE_EXTENSIONS_DENIED, FEATURES_RESTRICTED_FOLDERS_USERS, API_ITEMS_UNLOCK_THROTTLE_RATE.
Backend email matching is now normalized; the OIDC login mapping is unchanged in contract and the
cc-ci suite exercises the OIDC/IDP flow.
Advisory scan (drive 0.25.2→0.26.0 + redis/collabora/onlyoffice): 0 CVEs fixed by this
window; the release notes name none. One redis advisory reported unjudged by the scanner
(GHSA-2r7g-8hpc-rpq9) is scoped <= 8.0, so both endpoints here (8.10.2→8.10.3) are outside it.
Redis 8.10.3 remains a security patch (cluster-mode heap overflow); this stack is standalone.
Verification (before CI)
Direct --chaos deploy of this PR head on cc-ci (dev-lasuite-drive), fresh stack: 11/11 services 1/1, backend applied all migrations → migrate: done, gunicorn listening; app /
200 and web / 200; collabora 26.04 WSD initialization complete / Ready to accept connections on port 9980; onlyoffice /hosting/discovery 200; redis PONG. Torn down afterwards (0 stacks,
volumes, containers left).
Version label untouched (publishing is the operator's final step). Recommended release command:
abra recipe release lasuite-drive -y
(the app line has moved from the published v0.22.0 to v0.26.0 — features, so minor).
NOT merged — for operator review.
Tested green on the cc-ci recipe CI server (full suite, cold, against this PR head). NOT merged — for operator review.
## Upgrade: lasuite/drive v0.25.2 → v0.26.0 (extending this PR)
Extends the existing upgrade branch rather than opening a second PR. This adds the **v0.26.0**
app bump on top of the work already here (drive v0.25.3 + redis 8.10.3 + collabora 26.04.5.2.1 +
onlyoffice 10.0.2.1), so the PR tree now deploys drive **v0.26.0** with those sidecars.
| service | image | current (main) | new |
|---------|-------|----------------|-----|
| app | lasuite/drive-frontend | v0.25.2 | **v0.26.0** |
| backend | lasuite/drive-backend | v0.25.2 | **v0.26.0** |
| celery | lasuite/drive-backend | v0.25.2 | **v0.26.0** |
| celery-beat | lasuite/drive-backend | v0.25.2 | **v0.26.0** |
| redis | redis | 8.10.2 | **8.10.3** (already in branch) |
| collabora | collabora/code | 26.04.5.1.1 | **26.04.5.2.1** (already in branch) |
| onlyoffice | onlyoffice/documentserver-de | 10.0.0.1 | **10.0.2.1** (already in branch) |
Unchanged: minio `bitnamilegacy/minio:2025.7.23-debian-12-r5` (newest legacy tag),
pgautoupgrade `18-debian`, mailcatcher `v0.11.0`, nginx `1.31.8` (all already latest).
**Upstream release notes:**
- drive v0.25.3→v0.26.0: https://github.com/suitenumerique/drive/releases/tag/v0.26.0
- drive v0.25.2→v0.25.3: https://github.com/suitenumerique/drive/releases/tag/v0.25.3
- redis 8.10.2→8.10.3: https://github.com/redis/redis/releases/tag/8.10.3
- collabora 26.04.5.1.1→26.04.5.2.1: https://www.collaboraonline.com/release-notes/
- onlyoffice 10.0.0.1→10.0.2.1: https://github.com/ONLYOFFICE/DocumentServer/blob/master/CHANGELOG.md
### Operator Action Required
- **Drive v0.26.0** is a feature minor (upload denylist, share-link expiry/password, folder
restrictions, admin item-tree browse, WOPI logging). No declared breaking change and no new
**required** env. Django migrations run automatically on backend start.
- ⚠ **`RESTRICT_UPLOAD_FILE_TYPE` semantics changed**: it was a boolean, now an enum
`off` | `allowlist` | `denylist`, and **any other value stops backend startup**. This recipe does
not set it (defaults to `allowlist`), so a stock deploy is fine — but a deployer who set
`RESTRICT_UPLOAD_FILE_TYPE=true|false` in their `.env` must change it before deploying v0.26.0.
- New **optional** env (defaults safe, not added): `FILE_MIMETYPE_DENIED`,
`FILE_EXTENSIONS_DENIED`, `FEATURES_RESTRICTED_FOLDERS_USERS`, `API_ITEMS_UNLOCK_THROTTLE_RATE`.
- Backend email matching is now normalized; the OIDC login mapping is unchanged in contract and the
cc-ci suite exercises the OIDC/IDP flow.
- **Advisory scan** (drive 0.25.2→0.26.0 + redis/collabora/onlyoffice): **0 CVEs fixed by this
window**; the release notes name none. One redis advisory reported unjudged by the scanner
(`GHSA-2r7g-8hpc-rpq9`) is scoped `<= 8.0`, so both endpoints here (8.10.2→8.10.3) are outside it.
- Redis 8.10.3 remains a security patch (cluster-mode heap overflow); this stack is standalone.
### Verification (before CI)
Direct `--chaos` deploy of this PR head on cc-ci (`dev-lasuite-drive`), fresh stack:
**11/11 services 1/1**, backend applied all migrations → `migrate: done`, gunicorn listening; app `/`
200 and web `/` 200; collabora 26.04 `WSD initialization complete` / `Ready to accept connections on
port 9980`; onlyoffice `/hosting/discovery` 200; redis `PONG`. Torn down afterwards (0 stacks,
volumes, containers left).
Version label untouched (publishing is the operator's final step). Recommended release command:
`abra recipe release lasuite-drive -y`
(the app line has moved from the published `v0.22.0` to `v0.26.0` — features, so minor).
NOT merged — for operator review.
Tested green on the cc-ci recipe CI server (full suite, cold, against this PR head). NOT merged — for operator review.
cc @trav @notplants
collabora 26.04 images exec coolwsd directly (--use-env-vars; no shell in the
image), so the sh/start-collabora-online.sh entrypoint and extra_params env are
gone: ssl options move to command args, the healthcheck switches to
coolwsd --probe, and the admin panel password moves from the collabora_p
docker secret to the COLLABORA_ADMIN_PASSWORD env var (empty = locked).
redis 8.10.2 is a security release (transaction ACL-revocation bypass,
unauthenticated cluster-bus join; cache sidecar, no cluster mode here).
autonomic-bot
requested review from trav 2026-09-21 21:28:34 +00:00
autonomic-bot
requested review from notplants 2026-09-21 21:28:34 +00:00
autonomic-bot
changed title from chore: upgrade lasuite-drive redis to 8.10.2, collabora to 26.04.4.1.1 to chore: upgrade lasuite-drive to v0.23.0, collabora to 26.04.4.2.1; bump minio_initialize config to v22026-09-28 21:07:18 +00:00
autonomic-bot
changed title from chore: upgrade lasuite-drive to v0.23.0, collabora to 26.04.4.2.1; bump minio_initialize config to v2 to chore: upgrade lasuite-drive to v0.24.0, redis to 8.10.2, nginx to 1.31.7; collabora 26.04.4.2.12026-10-16 03:00:39 +00:00
!testme run 60 — RED at the upgrade BASE (external blocker, not this upgrade, not a test).
The harness resolved the upgrade base as the last-green data-warm canonical 0.12.0+v0.21.0 (warm-lasuite-drive.ci.commoninternet.net, idle, ts 2026-09-13) and its
pre-deploy prepull tried to pull that version's MinIO image, minio/minio:RELEASE.2025-09-07T16-13-09Z — a Docker Hub repo removed upstream:
prepull: pulling minio/minio:RELEASE.2025-09-07T16-13-09Z …
!! deploy/readiness failed: `docker pull minio/minio:RELEASE.2025-09-07T16-13-09Z` failed (rc=1)
— Error response from daemon: pull access denied for minio/minio, repository does not exist
install: fail (upgrade/backup/restore/custom: skip — the run never reached them)
This PR's head pins bitnamilegacy/minio:2025.7.23-debian-12-r5 (the upstream repoint) and is not the failing image. The local image store no longer caches the removed minio/minio tag
(it was present when this PR last ran green on 2026-09-28), so the base deploy now fails
deterministically before the upgrade tier runs.
Evidence the upgrade itself is correct (step 2b, direct --chaos deploy of this head on cc-ci):
11/11 services healthy (drive v0.24.0, redis 8.10.2, nginx 1.31.7, collabora 26.04.4.2.1, minio_initialize config v2), backend migrations applied (migrate: done), collabora 26.04 WSD initialization complete, web 200, redis PONG — torn down afterwards (0 leaks).
This is the same external base blocker the sibling lasuite-docs PR #9 hit today (its warm
canonical also prepulls the removed docker.io/minio/minio). It is a canonical/base-image issue, not a recipe regression and not a stale test assertion — no test was modified (DEFAULT mode).
Operator options to unblock: refresh/rebuild the data-warm canonical to a post-repoint version
(≥ 0.13.0+v0.22.0, which pins bitnamilegacy/minio), or add a tests/lasuite-drive/previous/
overlay (VERSION marker 0.12.0+v0.21.0) overriding the base's MinIO image. Re-running /recipe-upgrade lasuite-drive --with-tests would let the upgrader add that overlay.
1 / 3 !testme runs used — not spending the remaining budget on a deterministic external failure. Nothing merged.
<!-- cc-ci:upgrade-note -->
**`!testme` run 60 — RED at the upgrade BASE (external blocker, not this upgrade, not a test).**
The harness resolved the upgrade **base** as the last-green data-warm canonical
`0.12.0+v0.21.0` (`warm-lasuite-drive.ci.commoninternet.net`, idle, ts 2026-09-13) and its
pre-deploy **prepull** tried to pull that version's MinIO image,
`minio/minio:RELEASE.2025-09-07T16-13-09Z` — a Docker Hub repo **removed upstream**:
```
prepull: pulling minio/minio:RELEASE.2025-09-07T16-13-09Z …
!! deploy/readiness failed: `docker pull minio/minio:RELEASE.2025-09-07T16-13-09Z` failed (rc=1)
— Error response from daemon: pull access denied for minio/minio, repository does not exist
install: fail (upgrade/backup/restore/custom: skip — the run never reached them)
```
This PR's head pins `bitnamilegacy/minio:2025.7.23-debian-12-r5` (the upstream repoint) and is
**not** the failing image. The local image store no longer caches the removed `minio/minio` tag
(it was present when this PR last ran green on 2026-09-28), so the base deploy now fails
deterministically before the upgrade tier runs.
**Evidence the upgrade itself is correct** (step 2b, direct `--chaos` deploy of this head on cc-ci):
11/11 services healthy (drive `v0.24.0`, redis `8.10.2`, nginx `1.31.7`, collabora `26.04.4.2.1`,
`minio_initialize` config `v2`), backend migrations applied (`migrate: done`), collabora 26.04
`WSD initialization complete`, web `200`, redis `PONG` — torn down afterwards (0 leaks).
This is the **same external base blocker the sibling lasuite-docs PR #9 hit today** (its warm
canonical also prepulls the removed `docker.io/minio/minio`). It is a canonical/base-image issue,
**not a recipe regression and not a stale test assertion** — no test was modified (DEFAULT mode).
**Operator options to unblock:** refresh/rebuild the data-warm canonical to a post-repoint version
(≥ `0.13.0+v0.22.0`, which pins `bitnamilegacy/minio`), or add a `tests/lasuite-drive/previous/`
overlay (VERSION marker `0.12.0+v0.21.0`) overriding the base's MinIO image. Re-running
`/recipe-upgrade lasuite-drive --with-tests` would let the upgrader add that overlay.
1 / 3 `!testme` runs used — not spending the remaining budget on a deterministic external failure.
**Nothing merged.**
autonomic-bot
changed title from chore: upgrade lasuite-drive to v0.24.0, redis to 8.10.2, nginx to 1.31.7; collabora 26.04.4.2.1 to chore: upgrade drive to v0.25.2, nginx to 1.31.8; fix collabora 26.04 runtime contract2026-10-23 03:40:47 +00:00
!testme run 82 — RED at the upgrade BASE (external blocker, not this upgrade, not a test).
The harness resolved the upgrade base as the last-green data-warm canonical 0.12.0+v0.21.0 (warm-lasuite-drive, idle) and its pre-deploy prepull tried to pull that
version's MinIO image, minio/minio:RELEASE.2025-09-07T16-13-09Z — a Docker Hub repo removed
upstream:
== upgrade base: kind=version version=0.12.0+v0.21.0 (last-green (warm canonical, status=idle))
prepull: pulling collabora/code:25.04.10.3.1 …
prepull: pulling lasuite/drive-backend:v0.21.0 …
prepull: pulling lasuite/drive-frontend:v0.21.0 …
prepull: pulling minio/minio:RELEASE.2025-09-07T16-13-09Z …
!! deploy/readiness failed: prepull: `docker pull minio/minio:RELEASE.2025-09-07T16-13-09Z` failed (rc=1)
— pull access denied for minio/minio, repository does not exist or may require 'docker login'
install: fail (upgrade/backup/restore/custom: skip — the run never reached them)
This PR's head pins bitnamilegacy/minio:2025.7.23-debian-12-r5 (the upstream repoint) and is not
the failing image. The base tag is an immutable published recipe version, so the failure is
deterministic and identical to run 60 (2026-10-16) and to the sibling lasuite-docs PR #11 today — not a recipe regression and not a stale test assertion. No test was modified (DEFAULT mode).
Evidence the upgrade itself is correct (step 2b, direct --chaos deploy of this head 93c9d1a9 on cc-ci): 11/11 services 1/1 (drive v0.25.2, nginx 1.31.8, redis 8.10.2,
collabora 26.04.5.1.1, minio bitnamilegacy/…), backend applied all Django migrations
(migrate: done) then served under gunicorn, collabora WSD initialization complete + healthy
(coolwsd --probe) with /hosting/discovery → 200 through Traefik, web / → 200, minio health →
200. Torn down afterwards (0 stacks / 0 volumes / 0 env files).
This PR also carries a required recipe fix: upstream main pins collabora 26.04.5.1.1 but still
uses the pre-26.04 sh-based entrypoint + collabora_p secret. The 26.04 image has no shell, so
the base recipe as it stands cannot start collabora (exec: "sh": executable file not found).
The PR adapts it to the 26.04 runtime contract (command args + coolwsd --probe + env password).
Operator options to unblock: advance the lasuite-drive warm canonical to a release that pins bitnamilegacy/minio (≥ 0.13.0+v0.22.0), or add a tests/lasuite-drive/previous/ overlay
(VERSION 0.12.0+v0.21.0) overriding the base MinIO image. Then re-run !testme on this PR. --with-tests could add that overlay, but the upgrade itself needs no test change.
1 / 3 !testme runs used — not spending the remaining budget on a deterministic external failure. Nothing merged.
**`!testme` run 82 — RED at the upgrade BASE (external blocker, not this upgrade, not a test).**
The harness resolved the upgrade **base** as the last-green data-warm canonical
`0.12.0+v0.21.0` (`warm-lasuite-drive`, idle) and its pre-deploy **prepull** tried to pull that
version's MinIO image, `minio/minio:RELEASE.2025-09-07T16-13-09Z` — a Docker Hub repo **removed
upstream**:
```
== upgrade base: kind=version version=0.12.0+v0.21.0 (last-green (warm canonical, status=idle))
prepull: pulling collabora/code:25.04.10.3.1 …
prepull: pulling lasuite/drive-backend:v0.21.0 …
prepull: pulling lasuite/drive-frontend:v0.21.0 …
prepull: pulling minio/minio:RELEASE.2025-09-07T16-13-09Z …
!! deploy/readiness failed: prepull: `docker pull minio/minio:RELEASE.2025-09-07T16-13-09Z` failed (rc=1)
— pull access denied for minio/minio, repository does not exist or may require 'docker login'
install: fail (upgrade/backup/restore/custom: skip — the run never reached them)
```
This PR's head pins `bitnamilegacy/minio:2025.7.23-debian-12-r5` (the upstream repoint) and is **not**
the failing image. The base tag is an immutable published recipe version, so the failure is
deterministic and identical to run 60 (2026-10-16) and to the sibling lasuite-docs PR #11 today —
**not a recipe regression and not a stale test assertion**. No test was modified (DEFAULT mode).
**Evidence the upgrade itself is correct** (step 2b, direct `--chaos` deploy of this head
`93c9d1a9` on cc-ci): 11/11 services 1/1 (drive `v0.25.2`, nginx `1.31.8`, redis `8.10.2`,
collabora `26.04.5.1.1`, minio `bitnamilegacy/…`), backend applied all Django migrations
(`migrate: done`) then served under gunicorn, collabora `WSD initialization complete` + healthy
(`coolwsd --probe`) with `/hosting/discovery` → 200 through Traefik, web `/` → 200, minio health →
200. Torn down afterwards (0 stacks / 0 volumes / 0 env files).
> This PR also carries a required recipe fix: upstream main pins collabora `26.04.5.1.1` but still
> uses the pre-26.04 `sh`-based entrypoint + `collabora_p` secret. The 26.04 image has no shell, so
> the base recipe as it stands cannot start collabora (`exec: "sh": executable file not found`).
> The PR adapts it to the 26.04 runtime contract (command args + `coolwsd --probe` + env password).
**Operator options to unblock:** advance the lasuite-drive warm canonical to a release that pins
`bitnamilegacy/minio` (≥ `0.13.0+v0.22.0`), or add a `tests/lasuite-drive/previous/` overlay
(VERSION `0.12.0+v0.21.0`) overriding the base MinIO image. Then re-run `!testme` on this PR.
`--with-tests` could add that overlay, but the upgrade itself needs no test change.
1 / 3 `!testme` runs used — not spending the remaining budget on a deterministic external failure.
**Nothing merged.**
autonomic-bot
changed title from chore: upgrade drive to v0.25.2, nginx to 1.31.8; fix collabora 26.04 runtime contract to chore: upgrade drive to v0.25.3, redis to 8.10.3, collabora to 26.04.5.2.1, onlyoffice to 10.0.2.12026-10-30 03:57:47 +00:00
autonomic-bot
changed title from chore: upgrade drive to v0.25.3, redis to 8.10.3, collabora to 26.04.5.2.1, onlyoffice to 10.0.2.1 to chore: upgrade drive to v0.26.02026-11-06 04:26:04 +00:00
Superseded by upstream main — please close rather than merge
Heads-up from /recipe-upgrade lasuite-drive (2026-11-13): the mirror was re-synced to true upstream and main is now at 28042d1 (recipe 1.2.0+v0.27.0), which already carries drive v0.27.0, redis 8.10.3, collabora 26.04.6.1.1, onlyoffice 10.0.2.1, and the MinIO→RustFS replacement + migration tooling.
This PR bumps to drive v0.26.0on top of the older tree, so it is now behindmain; merging it would regress v0.27.0/RustFS back to v0.26.0/MinIO. It was left open and untouched (not force-pushed/closed/merged) for the operator to decide.
Recommendation: close this PR (no changes needed) since upstream main already contains a newer, verified recipe. Its last green !testme (run 136) was against the now-obsolete 64b8de4b head.
## Superseded by upstream `main` — please close rather than merge
Heads-up from `/recipe-upgrade lasuite-drive` (2026-11-13): the mirror was re-synced to true upstream and `main` is now at `28042d1` (**recipe `1.2.0+v0.27.0`**), which already carries drive `v0.27.0`, redis `8.10.3`, collabora `26.04.6.1.1`, onlyoffice `10.0.2.1`, and the MinIO→RustFS replacement + migration tooling.
This PR bumps to drive `v0.26.0` **on top of the older tree**, so it is now *behind* `main`; merging it would regress `v0.27.0`/RustFS back to `v0.26.0`/MinIO. It was left open and untouched (not force-pushed/closed/merged) for the operator to decide.
Recommendation: close this PR (no changes needed) since upstream `main` already contains a newer, verified recipe. Its last green `!testme` (run 136) was against the now-obsolete `64b8de4b` head.
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.
Upgrade: lasuite/drive v0.25.2 → v0.26.0 (extending this PR)
Extends the existing upgrade branch rather than opening a second PR. This adds the v0.26.0
app bump on top of the work already here (drive v0.25.3 + redis 8.10.3 + collabora 26.04.5.2.1 +
onlyoffice 10.0.2.1), so the PR tree now deploys drive v0.26.0 with those sidecars.
Unchanged: minio
bitnamilegacy/minio:2025.7.23-debian-12-r5(newest legacy tag),pgautoupgrade
18-debian, mailcatcherv0.11.0, nginx1.31.8(all already latest).Upstream release notes:
Operator Action Required
restrictions, admin item-tree browse, WOPI logging). No declared breaking change and no new
required env. Django migrations run automatically on backend start.
RESTRICT_UPLOAD_FILE_TYPEsemantics changed: it was a boolean, now an enumoff|allowlist|denylist, and any other value stops backend startup. This recipe doesnot set it (defaults to
allowlist), so a stock deploy is fine — but a deployer who setRESTRICT_UPLOAD_FILE_TYPE=true|falsein their.envmust change it before deploying v0.26.0.FILE_MIMETYPE_DENIED,FILE_EXTENSIONS_DENIED,FEATURES_RESTRICTED_FOLDERS_USERS,API_ITEMS_UNLOCK_THROTTLE_RATE.cc-ci suite exercises the OIDC/IDP flow.
window; the release notes name none. One redis advisory reported unjudged by the scanner
(
GHSA-2r7g-8hpc-rpq9) is scoped<= 8.0, so both endpoints here (8.10.2→8.10.3) are outside it.Verification (before CI)
Direct
--chaosdeploy of this PR head on cc-ci (dev-lasuite-drive), fresh stack:11/11 services 1/1, backend applied all migrations →
migrate: done, gunicorn listening; app/200 and web
/200; collabora 26.04WSD initialization complete/Ready to accept connections on port 9980; onlyoffice/hosting/discovery200; redisPONG. Torn down afterwards (0 stacks,volumes, containers left).
Version label untouched (publishing is the operator's final step). Recommended release command:
abra recipe release lasuite-drive -y(the app line has moved from the published
v0.22.0tov0.26.0— features, so minor).NOT merged — for operator review.
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 —
lasuite-drive@ce5308c7❌ failurefull logs · dashboard
chore: upgrade lasuite-drive redis to 8.10.2, collabora to 26.04.4.1.1to chore: upgrade lasuite-drive to v0.23.0, collabora to 26.04.4.2.1; bump minio_initialize config to v2!testme
🌻 cc-ci —
lasuite-drive@1ed910df✅ passedfull logs · dashboard
chore: upgrade lasuite-drive to v0.23.0, collabora to 26.04.4.2.1; bump minio_initialize config to v2to chore: upgrade lasuite-drive to v0.24.0, redis to 8.10.2, nginx to 1.31.7; collabora 26.04.4.2.1!testme
🌻 cc-ci —
lasuite-drive@5a38a20c❌ failurefull logs · dashboard
!testmerun 60 — RED at the upgrade BASE (external blocker, not this upgrade, not a test).The harness resolved the upgrade base as the last-green data-warm canonical
0.12.0+v0.21.0(warm-lasuite-drive.ci.commoninternet.net, idle, ts 2026-09-13) and itspre-deploy prepull tried to pull that version's MinIO image,
minio/minio:RELEASE.2025-09-07T16-13-09Z— a Docker Hub repo removed upstream:This PR's head pins
bitnamilegacy/minio:2025.7.23-debian-12-r5(the upstream repoint) and isnot the failing image. The local image store no longer caches the removed
minio/miniotag(it was present when this PR last ran green on 2026-09-28), so the base deploy now fails
deterministically before the upgrade tier runs.
Evidence the upgrade itself is correct (step 2b, direct
--chaosdeploy of this head on cc-ci):11/11 services healthy (drive
v0.24.0, redis8.10.2, nginx1.31.7, collabora26.04.4.2.1,minio_initializeconfigv2), backend migrations applied (migrate: done), collabora 26.04WSD initialization complete, web200, redisPONG— torn down afterwards (0 leaks).This is the same external base blocker the sibling lasuite-docs PR #9 hit today (its warm
canonical also prepulls the removed
docker.io/minio/minio). It is a canonical/base-image issue,not a recipe regression and not a stale test assertion — no test was modified (DEFAULT mode).
Operator options to unblock: refresh/rebuild the data-warm canonical to a post-repoint version
(≥
0.13.0+v0.22.0, which pinsbitnamilegacy/minio), or add atests/lasuite-drive/previous/overlay (VERSION marker
0.12.0+v0.21.0) overriding the base's MinIO image. Re-running/recipe-upgrade lasuite-drive --with-testswould let the upgrader add that overlay.1 / 3
!testmeruns used — not spending the remaining budget on a deterministic external failure.Nothing merged.
chore: upgrade lasuite-drive to v0.24.0, redis to 8.10.2, nginx to 1.31.7; collabora 26.04.4.2.1to chore: upgrade drive to v0.25.2, nginx to 1.31.8; fix collabora 26.04 runtime contract!testme
🌻 cc-ci —
lasuite-drive@93c9d1a9❌ failurefull logs · dashboard
!testmerun 82 — RED at the upgrade BASE (external blocker, not this upgrade, not a test).The harness resolved the upgrade base as the last-green data-warm canonical
0.12.0+v0.21.0(warm-lasuite-drive, idle) and its pre-deploy prepull tried to pull thatversion's MinIO image,
minio/minio:RELEASE.2025-09-07T16-13-09Z— a Docker Hub repo removedupstream:
This PR's head pins
bitnamilegacy/minio:2025.7.23-debian-12-r5(the upstream repoint) and is notthe failing image. The base tag is an immutable published recipe version, so the failure is
deterministic and identical to run 60 (2026-10-16) and to the sibling lasuite-docs PR #11 today —
not a recipe regression and not a stale test assertion. No test was modified (DEFAULT mode).
Evidence the upgrade itself is correct (step 2b, direct
--chaosdeploy of this head93c9d1a9on cc-ci): 11/11 services 1/1 (drivev0.25.2, nginx1.31.8, redis8.10.2,collabora
26.04.5.1.1, miniobitnamilegacy/…), backend applied all Django migrations(
migrate: done) then served under gunicorn, collaboraWSD initialization complete+ healthy(
coolwsd --probe) with/hosting/discovery→ 200 through Traefik, web/→ 200, minio health →200. Torn down afterwards (0 stacks / 0 volumes / 0 env files).
Operator options to unblock: advance the lasuite-drive warm canonical to a release that pins
bitnamilegacy/minio(≥0.13.0+v0.22.0), or add atests/lasuite-drive/previous/overlay(VERSION
0.12.0+v0.21.0) overriding the base MinIO image. Then re-run!testmeon this PR.--with-testscould add that overlay, but the upgrade itself needs no test change.1 / 3
!testmeruns used — not spending the remaining budget on a deterministic external failure.Nothing merged.
chore: upgrade drive to v0.25.2, nginx to 1.31.8; fix collabora 26.04 runtime contractto chore: upgrade drive to v0.25.3, redis to 8.10.3, collabora to 26.04.5.2.1, onlyoffice to 10.0.2.1!testme
🌻 cc-ci —
lasuite-drive@728238e0✅ passedfull logs · dashboard
chore: upgrade drive to v0.25.3, redis to 8.10.3, collabora to 26.04.5.2.1, onlyoffice to 10.0.2.1to chore: upgrade drive to v0.26.0!testme
🌻 cc-ci —
lasuite-drive@64b8de4b✅ passedfull logs · dashboard
Superseded by upstream
main— please close rather than mergeHeads-up from
/recipe-upgrade lasuite-drive(2026-11-13): the mirror was re-synced to true upstream andmainis now at28042d1(recipe1.2.0+v0.27.0), which already carries drivev0.27.0, redis8.10.3, collabora26.04.6.1.1, onlyoffice10.0.2.1, and the MinIO→RustFS replacement + migration tooling.This PR bumps to drive
v0.26.0on top of the older tree, so it is now behindmain; merging it would regressv0.27.0/RustFS back tov0.26.0/MinIO. It was left open and untouched (not force-pushed/closed/merged) for the operator to decide.Recommendation: close this PR (no changes needed) since upstream
mainalready contains a newer, verified recipe. Its last green!testme(run 136) was against the now-obsolete64b8de4bhead.View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.