chore: upgrade impress to v6.0.2 (yhub collaboration), nginx to 1.31.8, docspec 1.21.4 #11

Open
autonomic-bot wants to merge 2 commits from upgrade-v6.0.2 into main
Owner

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

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
autonomic-bot added 2 commits 2026-10-23 03:26:34 +00:00
- 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
Author
Owner

!testme

!testme
Author
Owner

🌻 cc-ci — lasuite-docs @ ae725c7e ❌ failure

cc-ci result card

level

full logs · dashboard

<!-- cc-ci:testme --> 🌻 **cc-ci** — `lasuite-docs` @ `ae725c7e` ❌ **failure** [![cc-ci result card](https://ci.autonomic.zone/runs/79/summary.png)](https://drone.ci.autonomic.zone/recipe-maintainers/cc-ci/79) [![level](https://ci.autonomic.zone/runs/79/badge.svg)](https://drone.ci.autonomic.zone/recipe-maintainers/cc-ci/79) [full logs](https://drone.ci.autonomic.zone/recipe-maintainers/cc-ci/79) · [dashboard](https://ci.autonomic.zone/)
Author
Owner

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.

## 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.
Some required checks failed
cc-ci/testme cc-ci: failure
You are not authorized to merge this pull request.
This pull request can be merged automatically.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin upgrade-v6.0.2:upgrade-v6.0.2
git checkout upgrade-v6.0.2
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: recipe-maintainers/lasuite-docs#11