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

82 Releases 305 Tags

RSS Feed
  • v32.5.4 b3bdb90209
    Compare

    Onebox v32.5.4
    Release / build-and-release (push) Successful in 20m13s
    Details
    Stable

    jkunz released this 2026-09-24 03:32:22 +00:00 | 156 commits to main since this release

    2026-09-24 - 32.5.4

    Fixes

    • Embed a single @lossless.org/client runtime, 1.5.1, in the release binaries. @apiclient.xyz/docker 9.x, which Onebox moved to in 32.5.2, brought its own @lossless.org/client 1.5.1 beside the 1.0.0 that Onebox, @push.rocks/smartmigration and @serve.zone/corestore 32.2.0 used, so the binary embedded both and the release workflow's check of the compiled binary refused it: release run 4681 of v32.5.3 failed with Mixed embedded @lossless.org/client runtime versions: 1.0.0, 1.5.1, and v32.5.3 has no binaries. v32.5.2 locked the same two versions and has no binaries either; its release run stopped earlier, at the test timeout described under 32.5.3. @serve.zone/corestore 32.4.1 pins @lossless.org/client 1.5.1, the version the Docker client uses, and Onebox moves its own client to 1.5.1 with it, so the binary now embeds one client runtime, 1.5.1, and passes the check.

    Maintenance

    • Move @serve.zone/corestore from 32.2.0 to 32.4.1, @lossless.org/client from 1.0.0 to 1.5.1 and @serve.zone/interfaces from 32.3.0 to 32.15.0 in package.json, pnpm-lock.yaml and the binary's deno.lock. Onebox uses only the database allocation type and functions of corestore's ts/corestore.database.ts, which is unchanged between the two versions, so the Corestore platform image pin stays as it is. Corestore 32.4.1 pins @serve.zone/interfaces 32.15.0, and the binary's lock resolved @serve.zone/api and @serve.zone/workloadinit, which accept any 32.x, to that copy while the pnpm install the tests run resolved them to Onebox's 32.3.0, so the binary would have run the CoreMail control client's desired-state normalization and digest from another interfaces release than the tests. Onebox now pins 32.15.0 itself and the pnpm lock is deduplicated, so Onebox, corestore, @serve.zone/api and @serve.zone/workloadinit resolve 32.15.0 in both the tests and the binary; only @serve.zone/appstore 32.1.1, which pins 32.3.0 exactly, keeps its own 32.3.0 copy. Of the interfaces changes between 32.3.0 and 32.15.0, only 32.7.1's reaches code Onebox runs: data.normalizeCoreMailCredentialVerifier also accepts an argon2id parameter block in m,p,t order and re-emits it as m,t,p, and Onebox already writes every verifier in m,t,p order, so its verifiers, desired state and digests are unchanged. Corestore 32.4.1 also moves @lossless.org/nosqldb from 10.3.0 to 10.5.0 and @lossless.org/objectstorage from 10.0.1 to 10.3.1, and the binary's lock moves @push.rocks/smartrust from 2.2.0 to 2.3.0. The deduplication also moves the pnpm install's ws from 8.21.1 to 8.21.3 and semver from 7.8.1 to 7.8.5, the versions the binary's lock already resolves, and, in the development tooling only, @push.rocks/smartexit from 2.0.3 to 2.2.0, @push.rocks/smartcli from 4.3.0 to 4.3.1, @push.rocks/smartconfig from 6.2.3 to 6.2.5 and the @types/node of four type packages from 26.5.1 to 26.6.1.
    • Run the check of the compiled binaries from scripts/verify-binary-embedded-packages.ts, which pnpm run build:binary now runs after it compiles, locally as in the release workflow; pnpm run verify:binary runs it on its own. The check was a script inline in the release workflow's Verify binary startup and embedded packages step, which a local build never ran, so a binary that embedded two versions of a package that must be embedded once only failed the release run after its tag was pushed, as release run 4681 of v32.5.3 did with Mixed embedded @lossless.org/client runtime versions: 1.0.0, 1.5.1. The check is unchanged: the x64 binary reports the package version, passes the OpsServer Typed RPC runtime self-test on port 39117, and embeds each of the eleven listed packages at its installed version, @lossless.org/client, @apiclient.xyz/docker, @serve.zone/workloadinit, @api.global/typedrequest, @api.global/typedserver and @api.global/typedsocket at that version only. It now reads the expected version from package.json, which the workflow checks against the tag beforehand, and it reads the embedded packages from the one directory the binary extracted with its npm packages, failing when there is not exactly one, where the inline step took the first directory it found. The self-test's temporary state and runtime directories are removed afterwards.
    Downloads