serve.zone/onebox
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 82 Wiki Activity

82 Releases 305 Tags

RSS Feed
  • v33.8.0 f82ffee3ae
    Compare

    Onebox v33.8.0
    Release / build-and-release (push) Failing after 27m36s
    Details
    Stable

    philkunz released this 2026-10-05 19:48:27 +00:00 | 45 commits to main since this release

    2026-10-05 - 33.8.0

    Features

    • Bundle the Cloudly App Store template 1.20.0 for Cloudly 33.15.0 through @serve.zone/appstore 32.20.0, moved from 32.19.0 in package.json, pnpm-lock.yaml and the binary's deno.lock. Onebox reads the App Store from the catalog this package bundles, so onebox appstore upgrade cloudly --version 1.20.0 needs this release. The template pins the Cloudly 33.15.0 image index code.foss.global/serve.zone/cloudly@sha256:7156b37a0ecba08e6a9803fd8bfd10da2b4f6970257077f7af8a57d947398a76 and raises minOneboxVersion from 32.4.0 to 33.8.0: Cloudly 33.15.0 needs the NoSQLDB 10.6.1 write-conflict fix of the Corestore 32.2.4 this release pins, so Onebox 33.7.0 and earlier refuse the upgrade with App requires Onebox >= 33.8.0; current version is <version>. Apart from that minimum and the reworded S3_BUCKET description (Cloudly's own bucket now also keeps workload logs), 1.20.0 differs from 1.19.0 only in its image and changelog. Cloudly 33.15.0 keeps workload logs in its own bucket and moves the data version from 0.24.0 to 0.25.0, so every upgrade from 1.19.0 or earlier runs the forward-only step runtime-log-attempts at Cloudly's first start, after the earlier steps the older installs need, and every earlier Cloudly refuses the migrated data (DOWNGRADE_NOT_SUPPORTED); stop Cloudly and take a verified backup (onebox backup create cloudly) before upgrading, and a rollback is onebox backup restore <backup-id> of that backup. Onebox enforces only minOneboxVersion; the other flags and the template changelog are the operator's. AppStoreManager takes the Onebox release it checks minOneboxVersion against as the oneboxVersion option, defaulting to the running release, so the App Store upgrade test now prepares the 1.20.0 upgrade from installs of 1.2.1 through 1.19.0 on Onebox 33.8.0 and checks that Onebox 33.7.0 refuses it from 1.19.0 with that exact message. App Store 32.20.0 keeps @serve.zone/interfaces 32.42.0, so no other serve.zone package moves. deno.lock was re-resolved from https://registry.npmjs.org/ after a build and changes only the App Store entry, pinned by SHA-512. In pnpm-lock.yaml only the App Store entry changes, pinned by SHA-512.

    Fixes

    • Pin the platform Corestore 32.2.4 by its multi-platform image index code.foss.global/serve.zone/corestore@sha256:5934215cc86c5b1d79fce5040a03341d7114abd00bc71329f255e76efc158aaf (linux/amd64 and linux/arm64), moved from 32.2.3 in ts/platform-images.ts. Corestore 32.2.4 is a maintenance release of the 32.2 line that moves @lossless.org/nosqldb from 10.3.0 to 10.6.1, which detects write conflicts when a statement runs, so a long transaction no longer starves; lab run 7b proved the fix. A completed engine conversion keeps running the image its journal names, so after the binary upgrade it still runs 32.2.3 until onebox migration corestore-engine --replace-completed-target-image moves it. That command admits 32.2.3 to 32.2.4 as a newer release of the same major, read from both images' org.opencontainers.image.version and version labels, which state 32.2.3 and 32.2.4 on both platforms. A new completed-target replacement test runs that move with this release's own pin. Corestore 32.2.3 can still open the data 32.2.4 wrote as long as no tenant created a partial index. The change adds no startup data migration.
    • Start a native Corestore owner, one Onebox created on a NoSQLDB Corestore release by a fresh install or a corestore-platform cutover since Onebox 32, on its own image when it is not this release's pin, and move it with the new offline onebox migration corestore-engine --replace-native-target-image <pin> --expected-prior-image <digest> --expected-target-container <id>. Startup demanded the SmartDB 5 engine conversion from every owner without a conversion journal whose image was not the pin, so a pin bump left such a host unable to start with no supported path forward. Without a conversion journal, startup now reads the release label of the immutable image the owner names: Corestore up to 6.x served SmartDB 5 and still requires the conversion, Corestore 7.0.0 and later serve NoSQLDB 10; a NoSQLDB owner of another major and an image that states no release are refused by their cause, and an older owner of the pinned major is told the exact command that moves it. The command mirrors --replace-completed-target-image: writer fence, pull by digest, release labels (newer, same major, and the release this Onebox pins, declared as oneboxCorestorePinnedRelease), readiness and inventory proofs, an attempt journaled in its own corestore-native-target record, the prior target retained as onebox-corestore-native-recovery-<n>, a restore before the commit and a resume with the same arguments; startup refuses a pending attempt with that command. A cross-major move and a downgrade stay refused, and a converted host is unchanged. The Docker handoff steps the conversion journal and the native owner share now take the owner's frame (its data volumes and the containers that are never its target), so both run the same code. The SmartDB 5 refusal now comes after Docker connects, because it reads the image label; startup connects Docker earlier for it, so this refusal and every other Corestore refusal that needs Docker still come before startup's first write (the hosted-app signing key, the admin UI domain and the first administrator). A Corestore deploy now refuses an owner configuration without an image instead of filling in the pin, so no ensure, restart or redeploy path can move a recorded owner to the pin; only the offline replacement commands do. migration corestore-engine --approve, the only command that starts the SmartDB 5 conversion, refuses a native owner before it writes or stops anything: an owner whose image states a NoSQLDB release, an image that states no release, and an owner with a native target record, naming the native command. migration corestore-engine --status reports a native owner's corestore-native-target record (owner: "native", its attempts, nativeTargetState and the resume command of a pending attempt) when there is no conversion journal. The change adds no startup data migration.

    Maintenance

    • Release tooling: pnpm 12.8.1 (from 12.7.0) and @git.zone/tsdeno ^1.15.0 (from ^1.14.1; tsdeno 2 is a separate migration). @git.zone/tsbuild ^5.1.2, @git.zone/tstest 7.1.0, @git.zone/tsrun ^3.0.2 and @types/node 26.6.3 are already current, @types/node stays below 26.6.4 until it is seven days old, and Onebox does not use @git.zone/tsdocker. In pnpm-lock.yaml the install also moved @api.global/typedrequest 9.0.2 from @push.rocks/lik 6.4.2 to 6.4.4, a version already in the tree, so no package enters or leaves it; no entry was rewritten to SHA-1.
    Downloads