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

51 Releases 272 Tags

RSS Feed
  • v32.5.7 70d2692c6c
    Compare

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

    jkunz released this 2026-09-24 13:06:04 +00:00 | 28 commits to main since this release

    2026-09-24 - 32.5.7

    Fixes

    • Let appstore install --secrets-stdin carry every secret the secret store holds. The CLI read the secrets as one JSON line of at most 64 KiB and refused any value with a line break, while the encrypted secret store holds values of up to 500 KiB and 1 MiB per service, so a Cloudly install whose WorkloadInit approval, a multiline JSON file secret of up to 500 KiB, exceeded 64 KiB or kept its line breaks could not be installed through the CLI. --secrets-stdin now reads a JSON object that may span several lines, up to 2 MiB, twice the store's bundle limit so the JSON escaping of a full bundle fits, and the daemon's control socket accepts the same. After parsing, the daemon refuses a value over 500 KiB or values over 1 MiB together through the store's own size check, assertServiceSecretSizes, which the store's validation now uses as well, and refuses a line break in a value whose declaration does not deliver it as a file. The store's bundle limit is named maximumServiceSecretBundleBytes.
    • Roll back the image a first-approval deployment pulled when accepting the approval fails. The deployment marked its pulled image candidate-active from a hook that ran before the approval owner's acceptance transaction and outside it, so when that transaction failed, the image stayed candidate-active, and when the deployment's rollback could not finish either, the recovery that later runs for the kept service only forgets a candidate-active image, so the pulled image was never removed. The deployment now passes the rollback-pending image to the stage as acceptedImageCleanup, and WorkloadInitApprovalsStore.installPending marks it candidate-active in the same transaction and service update that accept the operation and hold the service, only while the service still records that rollback-pending image. An acceptance that fails leaves the image rollback-pending for the rollback or the later recovery to remove. An accepted operation whose runtime replacement then fails keeps the image, because its service stays held and the rollback cannot remove a held runtime or the image it runs, and a resume of the operation runs it.

    Maintenance

    • Raise the release tooling to @git.zone/tsbundle ^2.15.0, from ^2.14.0, and @git.zone/tswatch ^4.0.1, from ^4.0.0; @git.zone/tsbuild ^5.0.0, @git.zone/tsdeno ^1.8.0, @git.zone/tsrun ^3.0.0 and @git.zone/tstest 6.2.0 are already current. tsbundle 2.15.0 places and matches includeFiles by one rule: a ** glob keeps its subdirectories, a plain-file entry of a base64ts bundle embeds under its name, and a dot-named file is matched only by a segment that names the dot. Onebox's one bundle, ./ts_web/index.ts in bundle mode, includes ./html/**/*.html, and html/ holds only index.html at its top level, so the built dist_serve keeps the same six files byte for byte. Onebox builds no base64ts output. The exact matching uses Node's fs.glob, which the release workflow's Node 22 and the image's Node 24 both provide. tswatch 4.0.1 copies the includeFiles of a bundle-mode bundle next to it, as tsbundle does, so pnpm run watch now writes dist_serve/index.html, which tswatch 4.0.0 left out. The pnpm lock resolves tswatch's own tsbundle to 2.15.0 as well, so the development tree holds one tsbundle, and moves tswatch's @push.rocks/smartwatch from 6.4.3 to 6.5.0; no runtime package moves, and the binary's deno.lock references neither tool and is unchanged. @types/node stays 26.6.1 and pnpm stays 12.4.2, because @types/node 26.6.2 and pnpm 12.5.0 to 12.6.0 are inside the seven-day release-age window.
    Downloads