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

62 Releases 283 Tags

RSS Feed
  • v32.17.0 2e83fbb5b4
    Compare

    v32.17.0
    Release / build-and-release (push) Failing after 10m53s
    Details
    Stable

    philkunz released this 2026-09-27 22:38:29 +00:00 | 31 commits to main since this release

    2026-09-27 - 32.17.0

    Features

    • Bundle the Cloudly App Store template 1.6.0 for Cloudly 33.3.0 through @serve.zone/appstore 32.6.0, moved from 32.5.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.6.0 on a host running template 1.2.1, 1.3.0, 1.4.0 or 1.5.0 needs this release. The template pins the Cloudly 33.3.0 image index code.foss.global/serve.zone/cloudly@sha256:fe1d10de09a8dc28f4dcf32b8e2cfed1ca7329b7d1b7405048a6e328afe5f9a6, keeps the 1.5.0 runtime contract (environment, both root-only secret files, platform OIDC, health check) and requires Onebox 32.4.0. It marks the upgrade breaking, migration-required, backup-before-upgrade and manual-review, because Onebox reads these flags from the target version alone: from 1.2.1 Cloudly still migrates its data forward only from 0.20.0 to 0.21.0 at the first start, and only the pre-upgrade backup goes back; from 1.4.0 and 1.5.0 there is no data step, but the template changelog names the service network egress settings, the database-endpoint-unselected and objectstorage-endpoint-unselected refusals and, from 1.4.0, the rollout order Cloudly 33.3.0 before Coreflow 33.2.0. Onebox enforces only minOneboxVersion; the other flags and the template changelog are the operator's, as the Cloudly upgrade runbook states. The App Store upgrade test now checks that 1.6.0 is the latest catalog version and prepares its upgrade from installs of 1.2.1 (Cloudly 32.9.1 image, as central runs), 1.3.0, 1.4.0 and 1.5.0 (Cloudly 33.0.0, 33.1.0 and 33.2.0 images). App Store 32.6.0 still pins @serve.zone/interfaces 32.3.0, so no other runtime package moves.

    Maintenance

    • Release tooling: @git.zone/tstest 6.3.2 and @git.zone/tsrun 3.0.1 (@types/node stays 26.6.2 until 26.6.3 clears the seven-day rule).

    • Move the dashboard to @serve.zone/catalog 33.0.0 (from 4.0.0) and @design.estate/dees-catalog 16.5.0 (from 10.0.0) in one step, with @design.estate/dees-element 3.3.0 (from the exact 3.0.0 pin, now ^3.3.0) in package.json and pnpm-lock.yaml, and @design.estate/dees-domtools 3.0.1 through them; catalog 33 requires dees-catalog 16, and a second copy of dees-catalog would register the same custom elements twice. pnpm dedupe moves dees-element's own dees-domtools from 3.0.0 to 3.0.1, so the bundle in dist_serve holds one copy each of dees-catalog, dees-element, dees-domtools and lit. The dashboard needed no source change: it does not use the app shell (dees-appui) whose 15.0.0 changes break hosts, nor dees-chart-area, and every property, event and method it binds on dees-simple-appdash, dees-simple-login, dees-table, dees-input-text, dees-tile, dees-button, DeesModal, DeesToast and DeesUpdater is unchanged; @serve.zone/catalog 32.0.0 and 33.0.0 change no sz-* element Onebox uses. What looks different comes from dees-catalog itself, for example dees-button's icon size and glyph inset (15.2.0), dees-simple-login without its own card border (13.5.0) and the xterm 6 based dees-chart-log in the service log views (14.0.0). All four packages are dashboard-only devDependencies, so they stay out of deno.lock and the binary's runtime graph; the binary grows by 3,238,976 bytes on both targets, almost all of it the larger dashboard bundle it embeds from dist_serve, to 553,573,176 bytes for x64 and 542,359,040 bytes for arm64, inside the size budgets. The browser render gate test/test.catalog-render.browser.ts now also requires the dees-* and sz-* elements the dashboard uses to be registered, which fails when a second catalog copy stops the bundle at a repeated customElements.define.

    • Guard every binary build with @git.zone/tsdeno 1.10.0, moved from 1.9.0 in package.json and pnpm-lock.yaml. .smartconfig.json pins denoVersion 2.9.4, so tsdeno refuses any other Deno before it compiles (and for tsdeno install), which replaces the deno eval version check build:binary ran first. Each target has a size floor, about 75 % of its built size: minSize 390 MiB for x64 and 385 MiB for arm64, because Deno 2.9 can exit 0 with a fraction of the binary when its npm downloads fail. After the size checks tsdeno runs the x64 binary once as onebox --version in an empty environment and requires exit code 0 and the @serve.zone/onebox v<version> line; the arm64 smoke check is skipped on an x64 builder as a foreign target. The move to tsdeno 1.10.0 alone leaves the binary sizes unchanged but for a few bytes; the release sizes are in the dees-catalog entry. Onebox stays on Deno 2.9.4: tsdeno 1.10.0 supports it, no Onebox defect is traced to it, and 2.9.7 would refuse the committed deno.lock, whose npm entries name the registry mirror's tarball URLs, so a move is its own change with a registry-neutral lock.

    Downloads