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.20.0 947f8236e7
    Compare

    v32.20.0
    Release / build-and-release (push) Failing after 12m42s
    Details
    Stable

    philkunz released this 2026-09-29 00:14:57 +00:00 | 23 commits to main since this release

    2026-09-28 - 32.20.0

    Features

    • Bundle the Cloudly App Store template 1.9.0 for Cloudly 33.6.0 through @serve.zone/appstore 32.9.0, moved from 32.8.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.9.0 on a host running template 1.2.1, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0 or 1.8.0 needs this release. The template pins the Cloudly 33.6.0 image index code.foss.global/serve.zone/cloudly@sha256:efcb200497b45ea14ef87155ac67a13a9be8eebd67801680122e84b9f3670c26, keeps the 1.8.0 runtime contract (environment, both root-only secret files, platform OIDC, health check) and requires Onebox 32.4.0; against 1.8.0 only its image and changelog differ. It marks the upgrade migration-required and backup-before-upgrade because from 1.8.0 and every earlier template Cloudly 33.6.0 runs the forward-only data step deployment-machine-user-grants from 0.22.0 to 0.23.0 at its first start, which keeps on every deployment machine user only the grants a capability check reads and permanently removes the rest, such as the { serviceId, capabilities } grants stored by Cloudly 11; from 1.6.0 and earlier the step runtime-session-protocol-offer from 0.21.0 to 0.22.0 runs before it, and from 1.2.1 the 0.20.0 to 0.21.0 migration of Cloudly 33.0.0 first. No step has an inverse, so stop Cloudly and take a verified backup before upgrading; only that backup goes back. It stays breaking and manual-review because the step removes stored grants and, from 1.7.0 and earlier, the deployment machine users of Cloudly 33.5.0 apply: a username and password deployer, an administrator's deployment reservation and a machine identity or registry bearer issued earlier are refused, so switch every such deployer to a machine-user token before upgrading. Let no deployment run while Cloudly upgrades. Cloudly 33.6.0 stops gracefully on SIGTERM and SIGINT within 8 seconds, below the 10-second stop grace of Docker, so stopping or restarting it no longer leaves a database transaction held and the next start no longer crash-loops on EFENCE_BUSY; the Cloudly 33.5.0 or earlier container that this upgrade stops still lacks that handler, so this one upgrade can still meet the EFENCE_BUSY crash loop until the database server's 30-minute session timeout. The template changelog also names the per-service deployment namespace of new services and the repaired getDeploymentMachineUsers listing, and carries forward the notes of the earlier templates, with the rollout order Cloudly 33.6.0 before Coreflow 33.2.0 from 1.4.0 and earlier. 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.9.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, 1.5.0, 1.6.0, 1.7.0 and 1.8.0 (Cloudly 33.0.0, 33.1.0, 33.2.0, 33.3.0, 33.4.0 and 33.5.0 images). App Store 32.9.0 still pins @serve.zone/interfaces 32.3.0, so no other runtime package moves.
    Downloads