fix(sandbox): boot re-execs the script the bundle just installed, and a merge releases - #7637

Follow-up to #7620/#7622/#7633. Two halves of one problem, found while trying to verify those in a real box.

The bundle moved; the image didn't

push: paths: packages/sandbox/bundle/**   → publish-bundle     (automatic)
workflow_dispatch: production-release     → image + goldens    (manual)

So the bundle was republished on every merge and the image only when someone remembered. Every new box booted an image older than the bundle it then fetched.

Which exposed a real bug

ensure_bundle installs the pinned bundle, then apply-rootfs copies its rootfs over /usr/local/bin/superset-boot. But the shell is still running the copy the image baked. The script already knew about half of this:

# apply-rootfs may have replaced the contract; re-read it.
. /etc/superset/contract.sh

It re-read the contract and not itself. So a bundle change to the boot script took effect on the boot after the one that installed it.

That is what I hit verifying #7620: the box received "baseBranch":"main" correctly, the new script's parsing was right in isolation, and the checkout log still showed the pre-change git clone --branch <working branch> — the old script ran, and the same repository was cloned twice. Boot now re-execs when apply-rootfs changed it, guarded by SUPERSET_BOOT_REEXEC so a script that never settles can't spin.

And closes the drift

production-release now also runs on a merge to main touching packages/sandbox/**, packages/host-service/** or packages/pty-daemon/** — the three that reach a box only through a release. The job's concurrency: sandbox-production-release already serialises, and GitHub collapses a burst of pending runs to the newest.

Not extended to TRIGGER_TYPE_RECURRING, which is worth considering separately: it's what the competing product uses alongside config-change to stop a snapshot drifting behind the repo when nothing about the environment itself changed.

Verified

• bash -n on superset-boot; bun test packages/sandbox 9 pass / 0 fail; repo lint clean
• The re-exec path itself is exercised by the first box that boots an image predating this bundle — which is the next release, and what I'll be watching in the boot log (boot.reexec).

Note

The job carries environment: production. If that GitHub environment has required reviewers, these automatic runs will wait for approval rather than proceeding — fine either way, but worth knowing which it is.

Summary by cubic

Fixes sandbox release drift and a boot race. Previously a merge to main republished the bundle while the image released only on manual dispatch, so a new box booted an image older than the bundle it fetched. The boot script also kept running the image's copy after apply-rootfs installed a new one, so a bundle change took effect one boot late.

• production-release now triggers on a main merge touching packages/sandbox/** in addition to manual dispatch. packages/host-service/** is deliberately not included: a box picks host-service up by hash from bundle/assets.json, so what reaches a box is the version bump in that file, which is already a packages/sandbox/** change. The concurrency group serialises runs and GitHub collapses a burst of pending runs to the newest; the job carries environment: production, so automatic runs wait for approval if that environment has required reviewers.
• Boot now re-execs into the script the bundle installed when its hash changed, once per boot via the SUPERSET_BOOT_REEXEC guard so a script that never settles can't spin. TRIGGER_TYPE_RECURRING was intentionally left out and is worth deciding separately.

^{Written for commit 92f2202. Summary will update on new commits.}

Summary by CodeRabbit

• New Features

  • Boot-time updates to the system startup process now take effect immediately, without requiring an additional reboot.

• Chores

  • Sandbox-related changes are now included more reliably in automated release checks.
  • Production releases can now run automatically when changes reach the main branch, as well as through manual release requests.