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

59 Releases 280 Tags

RSS Feed
  • v32.19.0 c7af7566b5
    Compare

    v32.19.0
    Release / build-and-release (push) Failing after 11m16s
    Details
    Stable

    philkunz released this 2026-09-28 13:24:56 +00:00 | 2 commits to main since this release

    2026-09-28 - 32.19.0

    Features

    • Bundle the Cloudly App Store template 1.8.0 for Cloudly 33.5.0 through @serve.zone/appstore 32.8.0, moved from 32.7.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.8.0 on a host running template 1.2.1, 1.3.0, 1.4.0, 1.5.0, 1.6.0 or 1.7.0 needs this release. The template pins the Cloudly 33.5.0 image index code.foss.global/serve.zone/cloudly@sha256:9a803fbc9db00ffcf6ce4bd584c0c8b5a3016f3a94ce75629ddee2f52d2bf72c, keeps the 1.7.0 runtime contract (environment, both root-only secret files, platform OIDC, health check) and requires Onebox 32.4.0; against 1.7.0 only its image and changelog differ. It marks the upgrade breaking and manual-review because Cloudly 33.5.0 reserves a deployment only for a deployment machine user: reserveServiceDeployment refuses an administrator, and so a username and password deployer such as tsdeploy with TSDEPLOY_CLOUDLY_USERNAME/TSDEPLOY_CLOUDLY_PASSWORD, with DEPLOYMENT_MACHINE_IDENTITY_REQUIRED, so operators switch every such deployer to a machine-user token (mutateDeploymentMachineUser or Access → Deployment machine users, grants through configureServiceDeploymentMachineUser) before upgrading; a machine identity or registry bearer issued by an earlier release is refused until its holder exchanges its token again, and a deployment in progress during the upgrade is refused for the rest of its run, so no deployment runs while Cloudly upgrades. It stays migration-required and backup-before-upgrade, because Onebox reads these flags from the target version alone: Cloudly 33.5.0 keeps data version 0.22.0 and only adds the collection cloudly_deployment_machine_user_mutations, so from 1.7.0 there is no data step, while from 1.6.0 and earlier the forward-only step runtime-session-protocol-offer from 0.21.0 to 0.22.0 still runs at the first start, and from 1.2.1 the 0.20.0 to 0.21.0 migration of Cloudly 33.0.0 before it; neither step has an inverse, so only the pre-upgrade backup goes back. The template changelog also names the relay config push to the elected relay of every cluster and the invalid refusal of setServiceRuntimeSpec, and carries forward the notes of the earlier templates, with the rollout order Cloudly 33.5.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.8.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 and 1.7.0 (Cloudly 33.0.0, 33.1.0, 33.2.0, 33.3.0 and 33.4.0 images). App Store 32.8.0 still pins @serve.zone/interfaces 32.3.0, so no other runtime package moves.

    Maintenance

    • Release tooling: @git.zone/tsdeno 1.12.0, moved from 1.11.0 in package.json and pnpm-lock.yaml. Before every compile and after every tsdeno install --entrypoint it reads the binary's module graph with deno info under the run's resolution flags, including the minimumDependencyAge committed in deno.json, and fails with UNRESOLVED_DEPENDENCY when an npm import does not resolve, because Deno 2.9 exits 0 and leaves such a package out of a binary it reaches only through a dynamic import. Onebox's graph resolves completely, so build:binary passes the new guard unchanged. pnpm 12.6.0 and @types/node 26.6.3 still wait for the seven-day rule.
    Downloads