Making the mirror PR the v6 upgrade. Upstream main already carries the v6.0.1 image tags (Renovate commits) but not the v6 collaboration-stack adaptation, so the recipe on main is a v6 image swap without the required new services/config. This PR adds the full v6 adaptation (from upstream upgrade-v6, upstream PR #40, commit 3c87e66) and moves it to v6.0.2 + nginx 1.31.8, plus the docspec 1.x switch.
This supersedes mirror PR #9 (v5.7.0): upstream main has since moved to the v6 image line, so #9's tree is behind main. #9 is left open for the operator.
Image changes (vs upstream main 32cc9b0)
service
image
main
this PR
app
lasuite/impress-frontend
v6.0.1
v6.0.2
backend
lasuite/impress-backend
v6.0.1
v6.0.2
celery
lasuite/impress-backend
v6.0.1
v6.0.2
y-provider
lasuite/impress-y-provider
v6.0.1
v6.0.2
yhub
lasuite/impress-yhub
(absent)
v6.0.2 (new)
yhub-valkey
valkey/valkey
(absent)
8.1.10-alpine (new)
jwt-keys
lasuite/impress-yhub
(absent)
v6.0.2 (new recipe sidecar)
docspec
ghcr.io/docspecio/api → ghcr.io/docspec/api
3.0.2
1.21.4 (+ port 4000→3000)
web
nginx
1.31.7
1.31.8
redis
redis
8.10.2
unchanged
minio
bitnamilegacy/minio
2025.7.23-debian-12-r5
unchanged
db
pgautoupgrade/pgautoupgrade
18-debian
unchanged
Recipe version label is untouched (0.4.4+v5.6.1) per the upgrade workflow.
Operator action required (v6 is breaking)
Collaboration stack replaced.yhub (port 3002) takes over /collaboration/*; y-provider is now conversion-only. New yhub-valkey and an own yhub database on the existing postgres. COLLABORATION_SERVER_SECRET / collab_ss is gone.
RSA keys. The backend and yhub each need their own RSA key. The recipe auto-generates both on first deploy into the jwt_keys volume via the jwt-keys sidecar (Node crypto) and reuses them on later deploys. They are deliberately not Swarm secrets: abra cannot generate PEM (generate=false) and Swarm secrets must exist before docker stack deploy, which would break fresh installs and the CI upgrade tier. No manual key step.
Document migration.SOFT_MIGRATION defaults to true (lazy seed from the legacy S3 bucket the first time a doc is opened). Then backfill everything: abra app cmd <app-name> backend migrate_documents (new abra.sh command; supports --dry-run, --retry-failed). Only then set SOFT_MIGRATION=false. Keep the legacy {id}/file objects and their versions — they are the pre-v6 history.
v6.0.2 yhub schema. Upstream moved to @y/hub 0.10.1 and added the yhub_ydoc_versions_v1 table; the recipe's init-db runs on every yhub start (idempotent), so the schema script is applied automatically.
External API policy. v6.0.2 denies resource-server actions unless explicitly listed in the matching EXTERNAL_APIactions (favorites/duplicate/onboarding as applicable). Only relevant if you enabled the resource server.
Backups now include the yhub database (backup-yhub.sql).
Recommended release (operator, after merge)
abra recipe release lasuite-docs -x
(-x = breaking major for operators: new services + document migration + removed collab_ss. No --dry-run.)
Verification
abra recipe lint — all rules pass (R002 healthcheck now satisfied by jwt-keys too).
Live abra app deploy --chaos of this head on dev-lasuite-docs.ci.commoninternet.net: 12/12 services converged — backend applied all migrations (gunicorn on :8000), yhub init-db + /collaboration/ready/v1 → 200, yhub-valkey healthy, docspec /health → Healthy., nginx 1.31.8 root → 200, backend JWKS → 200. Dev deploy torn down; 0 stacks / 0 services / 0 volumes / 0 secrets leaked.
Advisory scan (6.0.1→6.0.2, nginx 1.31.7→1.31.8, docspec 3.0.2→1.21.4): 0 CVEs fixed in this window. All 57 adjudication items are historical nginx CVEs fixed in ≤1.31.7; nginx 1.31.8 CHANGES contains no security entries. Scan source warnings are the internal docspec:3000 health URL only.
Making the mirror PR the v6 upgrade. Upstream main already carries the **v6.0.1 image tags** (Renovate commits) but **not** the v6 collaboration-stack adaptation, so the recipe on main is a v6 image swap without the required new services/config. This PR adds the full v6 adaptation (from upstream `upgrade-v6`, upstream PR #40, commit `3c87e66`) and moves it to **v6.0.2** + **nginx 1.31.8**, plus the docspec 1.x switch.
This **supersedes mirror PR #9** (v5.7.0): upstream main has since moved to the v6 image line, so #9's tree is behind main. #9 is left open for the operator.
## Image changes (vs upstream main `32cc9b0`)
| service | image | main | this PR |
|---|---|---|---|
| app | lasuite/impress-frontend | v6.0.1 | **v6.0.2** |
| backend | lasuite/impress-backend | v6.0.1 | **v6.0.2** |
| celery | lasuite/impress-backend | v6.0.1 | **v6.0.2** |
| y-provider | lasuite/impress-y-provider | v6.0.1 | **v6.0.2** |
| yhub | lasuite/impress-yhub | *(absent)* | **v6.0.2 (new)** |
| yhub-valkey | valkey/valkey | *(absent)* | **8.1.10-alpine (new)** |
| jwt-keys | lasuite/impress-yhub | *(absent)* | **v6.0.2 (new recipe sidecar)** |
| docspec | ghcr.io/docspecio/api → ghcr.io/docspec/api | 3.0.2 | **1.21.4** (+ port 4000→3000) |
| web | nginx | 1.31.7 | **1.31.8** |
| redis | redis | 8.10.2 | unchanged |
| minio | bitnamilegacy/minio | 2025.7.23-debian-12-r5 | unchanged |
| db | pgautoupgrade/pgautoupgrade | 18-debian | unchanged |
Recipe version label is **untouched** (`0.4.4+v5.6.1`) per the upgrade workflow.
## Operator action required (v6 is breaking)
- **Collaboration stack replaced.** `yhub` (port 3002) takes over `/collaboration/*`; `y-provider` is now conversion-only. New `yhub-valkey` and an own `yhub` database on the existing postgres. `COLLABORATION_SERVER_SECRET` / `collab_ss` is gone.
- **RSA keys.** The backend and yhub each need their own RSA key. The recipe **auto-generates both** on first deploy into the `jwt_keys` volume via the `jwt-keys` sidecar (Node crypto) and reuses them on later deploys. They are deliberately **not** Swarm secrets: abra cannot generate PEM (`generate=false`) and Swarm secrets must exist before `docker stack deploy`, which would break fresh installs and the CI upgrade tier. No manual key step.
- **Document migration.** `SOFT_MIGRATION` defaults to `true` (lazy seed from the legacy S3 bucket the first time a doc is opened). Then backfill everything: `abra app cmd <app-name> backend migrate_documents` (new `abra.sh` command; supports `--dry-run`, `--retry-failed`). Only then set `SOFT_MIGRATION=false`. Keep the legacy `{id}/file` objects **and their versions** — they are the pre-v6 history.
- **v6.0.2 yhub schema.** Upstream moved to `@y/hub 0.10.1` and added the `yhub_ydoc_versions_v1` table; the recipe's `init-db` runs on **every** yhub start (idempotent), so the schema script is applied automatically.
- **External API policy.** v6.0.2 denies resource-server actions unless explicitly listed in the matching `EXTERNAL_API` `actions` (favorites/duplicate/onboarding as applicable). Only relevant if you enabled the resource server.
- **Backups** now include the `yhub` database (`backup-yhub.sql`).
## Recommended release (operator, after merge)
```
abra recipe release lasuite-docs -x
```
(`-x` = breaking major for operators: new services + document migration + removed `collab_ss`. No `--dry-run`.)
## Verification
- `abra recipe lint` — all rules pass (R002 healthcheck now satisfied by `jwt-keys` too).
- Live `abra app deploy --chaos` of this head on `dev-lasuite-docs.ci.commoninternet.net`: **12/12 services converged** — backend applied all migrations (gunicorn on `:8000`), yhub `init-db` + `/collaboration/ready/v1` → 200, yhub-valkey healthy, docspec `/health` → `Healthy.`, nginx 1.31.8 root → 200, backend JWKS → 200. Dev deploy torn down; **0 stacks / 0 services / 0 volumes / 0 secrets leaked**.
- Advisory scan (6.0.1→6.0.2, nginx 1.31.7→1.31.8, docspec 3.0.2→1.21.4): **0 CVEs fixed in this window**. All 57 adjudication items are historical nginx CVEs fixed in ≤1.31.7; nginx 1.31.8 `CHANGES` contains no security entries. Scan source warnings are the internal `docspec:3000` health URL only.
## Upstream release notes
**Upstream release notes:** app/backend/celery/y-provider/yhub v6.0.1→v6.0.2: https://github.com/suitenumerique/docs/releases/tag/v6.0.2
**Upstream release notes:** v6.0.0 collaboration-stack migration (required context): https://github.com/suitenumerique/docs/releases/tag/v6.0.0 · https://github.com/suitenumerique/docs/blob/main/UPGRADE.md
**Upstream release notes:** web nginx 1.31.7→1.31.8: https://nginx.org/en/CHANGES
**Upstream release notes:** docspec 3.0.2→1.21.4: https://github.com/docspec/docspec/releases
cc @trav @notplants
- the new yhub service needs new initialisation and RSA keys
- SOFT_MIGRATION on by default, add migrate_documents command
- back up the yhub database too
- document the v5 -> v6 upgrade in README and release/next
Following the [C4DT AI Policy](https://git.coopcloud.tech/c4dt/ai-policy/src/branch/main/AI-POLICY.md):
#LLM_vibe
#LLM_model Claude Opus 5.5
- [x] I take full responsibility for this code
- [x] I understand every line of this code
- [x] I tested this code thoroughly on my own computer / servers
- [x] None of the commit messages were created using LLMs
- [x] I will participate in any discussion on my own and will not use an LLM for the discussion
== upgrade base: kind=version version=0.4.0+v5.4.1 (last-green (warm canonical, status=idle))
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
— pull access denied for minio/minio, repository does not exist or may require 'docker login'
The chosen upgrade base is the data-warm canonical warm-lasuite-docs = 0.4.0+v5.4.1 (commit f47e452, registry /var/lib/ci-warm/lasuite-docs/canonical.json). That published tag pins docker.io/minio/minio:RELEASE.2025-09-07T16-13-09Z, and the minio/minio Docker Hub repo was
removed upstream. The failure is in prepulling the base, before any PR-head code is deployed, and
every later rung (upgrade/backup/restore/custom) is skipped. It is not this PR:
the head uses bitnamilegacy/minio (already on upstream main) and the v6.0.2 images.
Evidence the head itself is healthy: abra recipe lint passes all rules, and a direct abra app deploy --chaos of exactly this head on dev-lasuite-docs.ci.commoninternet.net converged 12/12 services (backend migrations + gunicorn, yhub init-db + /collaboration/ready/v1 200,
yhub-valkey, docspec /health, nginx 1.31.8 root 200, JWKS 200), then was torn down with 0 stacks /
0 services / 0 volumes / 0 secrets leaked.
Unblock (CI infra, not this PR): advance the lasuite-docs warm canonical to a release that carries
the relocated minio — 0.4.3+v5.6.1 or 0.4.4+v5.6.1 both use bitnamilegacy/minio. That happens via
a green cold-on-latest run (canonical promotion; !testme with a PR head deliberately never
promotes). After the canonical advances, re-run !testme here and the upgrade tier will cross 0.4.4+v5.6.1 → v6.0.2. No test or harness file was modified (DEFAULT mode).
Also note this PR supersedes #9 (v5.7.0), which is behind main's v6 image line.
## cc-ci `!testme` — RED at the upgrade **base prepull** (external, not this PR)
Run: https://drone.ci.autonomic.zone/recipe-maintainers/cc-ci/79 (PR head `ae725c7e`)
```
== upgrade base: kind=version version=0.4.0+v5.4.1 (last-green (warm canonical, status=idle))
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
— pull access denied for minio/minio, repository does not exist or may require 'docker login'
```
The chosen upgrade base is the data-warm canonical `warm-lasuite-docs` = **`0.4.0+v5.4.1`** (commit
`f47e452`, registry `/var/lib/ci-warm/lasuite-docs/canonical.json`). That published tag pins
**`docker.io/minio/minio:RELEASE.2025-09-07T16-13-09Z`**, and the `minio/minio` Docker Hub repo was
removed upstream. The failure is in prepulling the **base**, before any PR-head code is deployed, and
every later rung (upgrade/backup/restore/custom) is skipped. It is **not** this PR:
the head uses `bitnamilegacy/minio` (already on upstream main) and the v6.0.2 images.
Evidence the head itself is healthy: `abra recipe lint` passes all rules, and a direct
`abra app deploy --chaos` of exactly this head on `dev-lasuite-docs.ci.commoninternet.net` converged
**12/12 services** (backend migrations + gunicorn, yhub `init-db` + `/collaboration/ready/v1` 200,
yhub-valkey, docspec `/health`, nginx 1.31.8 root 200, JWKS 200), then was torn down with **0 stacks /
0 services / 0 volumes / 0 secrets leaked**.
**Unblock (CI infra, not this PR):** advance the lasuite-docs warm canonical to a release that carries
the relocated minio — `0.4.3+v5.6.1` or `0.4.4+v5.6.1` both use `bitnamilegacy/minio`. That happens via
a green **cold-on-latest** run (canonical promotion; `!testme` with a PR head deliberately never
promotes). After the canonical advances, re-run `!testme` here and the upgrade tier will cross
`0.4.4+v5.6.1 → v6.0.2`. No test or harness file was modified (DEFAULT mode).
Also note this PR supersedes #9 (v5.7.0), which is behind main's v6 image line.
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.
Making the mirror PR the v6 upgrade. Upstream main already carries the v6.0.1 image tags (Renovate commits) but not the v6 collaboration-stack adaptation, so the recipe on main is a v6 image swap without the required new services/config. This PR adds the full v6 adaptation (from upstream
upgrade-v6, upstream PR #40, commit3c87e66) and moves it to v6.0.2 + nginx 1.31.8, plus the docspec 1.x switch.This supersedes mirror PR #9 (v5.7.0): upstream main has since moved to the v6 image line, so #9's tree is behind main. #9 is left open for the operator.
Image changes (vs upstream main
32cc9b0)Recipe version label is untouched (
0.4.4+v5.6.1) per the upgrade workflow.Operator action required (v6 is breaking)
yhub(port 3002) takes over/collaboration/*;y-provideris now conversion-only. Newyhub-valkeyand an ownyhubdatabase on the existing postgres.COLLABORATION_SERVER_SECRET/collab_ssis gone.jwt_keysvolume via thejwt-keyssidecar (Node crypto) and reuses them on later deploys. They are deliberately not Swarm secrets: abra cannot generate PEM (generate=false) and Swarm secrets must exist beforedocker stack deploy, which would break fresh installs and the CI upgrade tier. No manual key step.SOFT_MIGRATIONdefaults totrue(lazy seed from the legacy S3 bucket the first time a doc is opened). Then backfill everything:abra app cmd <app-name> backend migrate_documents(newabra.shcommand; supports--dry-run,--retry-failed). Only then setSOFT_MIGRATION=false. Keep the legacy{id}/fileobjects and their versions — they are the pre-v6 history.@y/hub 0.10.1and added theyhub_ydoc_versions_v1table; the recipe'sinit-dbruns on every yhub start (idempotent), so the schema script is applied automatically.EXTERNAL_APIactions(favorites/duplicate/onboarding as applicable). Only relevant if you enabled the resource server.yhubdatabase (backup-yhub.sql).Recommended release (operator, after merge)
(
-x= breaking major for operators: new services + document migration + removedcollab_ss. No--dry-run.)Verification
abra recipe lint— all rules pass (R002 healthcheck now satisfied byjwt-keystoo).abra app deploy --chaosof this head ondev-lasuite-docs.ci.commoninternet.net: 12/12 services converged — backend applied all migrations (gunicorn on:8000), yhubinit-db+/collaboration/ready/v1→ 200, yhub-valkey healthy, docspec/health→Healthy., nginx 1.31.8 root → 200, backend JWKS → 200. Dev deploy torn down; 0 stacks / 0 services / 0 volumes / 0 secrets leaked.CHANGEScontains no security entries. Scan source warnings are the internaldocspec:3000health URL only.Upstream release notes
Upstream release notes: app/backend/celery/y-provider/yhub v6.0.1→v6.0.2: https://github.com/suitenumerique/docs/releases/tag/v6.0.2
Upstream release notes: v6.0.0 collaboration-stack migration (required context): https://github.com/suitenumerique/docs/releases/tag/v6.0.0 · https://github.com/suitenumerique/docs/blob/main/UPGRADE.md
Upstream release notes: web nginx 1.31.7→1.31.8: https://nginx.org/en/CHANGES
Upstream release notes: docspec 3.0.2→1.21.4: https://github.com/docspec/docspec/releases
cc @trav @notplants
!testme
🌻 cc-ci —
lasuite-docs@ae725c7e❌ failurefull logs · dashboard
cc-ci
!testme— RED at the upgrade base prepull (external, not this PR)Run: https://drone.ci.autonomic.zone/recipe-maintainers/cc-ci/79 (PR head
ae725c7e)The chosen upgrade base is the data-warm canonical
warm-lasuite-docs=0.4.0+v5.4.1(commitf47e452, registry/var/lib/ci-warm/lasuite-docs/canonical.json). That published tag pinsdocker.io/minio/minio:RELEASE.2025-09-07T16-13-09Z, and theminio/minioDocker Hub repo wasremoved upstream. The failure is in prepulling the base, before any PR-head code is deployed, and
every later rung (upgrade/backup/restore/custom) is skipped. It is not this PR:
the head uses
bitnamilegacy/minio(already on upstream main) and the v6.0.2 images.Evidence the head itself is healthy:
abra recipe lintpasses all rules, and a directabra app deploy --chaosof exactly this head ondev-lasuite-docs.ci.commoninternet.netconverged12/12 services (backend migrations + gunicorn, yhub
init-db+/collaboration/ready/v1200,yhub-valkey, docspec
/health, nginx 1.31.8 root 200, JWKS 200), then was torn down with 0 stacks /0 services / 0 volumes / 0 secrets leaked.
Unblock (CI infra, not this PR): advance the lasuite-docs warm canonical to a release that carries
the relocated minio —
0.4.3+v5.6.1or0.4.4+v5.6.1both usebitnamilegacy/minio. That happens viaa green cold-on-latest run (canonical promotion;
!testmewith a PR head deliberately neverpromotes). After the canonical advances, re-run
!testmehere and the upgrade tier will cross0.4.4+v5.6.1 → v6.0.2. No test or harness file was modified (DEFAULT mode).Also note this PR supersedes #9 (v5.7.0), which is behind main's v6 image line.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.