[ci] Publish the Hero OS desktop (WASM) bundle in release CI and install it on members #159
Labels
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/hero_os#159
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The release workflow for hero_os builds and publishes only the three service binaries (hero_os, hero_os_server, hero_os_admin) and skips the Dioxus WASM desktop frontend (hero_os_app). But hero_os_admin serves that desktop from an external assets directory (~/hero/share/hero_os/public) and refuses to start if index.html is missing, so a freshly installed member has the binaries but no desktop and the admin service stays failed. We delivered the desktop to the current testers by hand, which any fresh install or update wipes. Could we add a step to the release workflow that builds the desktop bundle (dx build of hero_os_app for the web platform, needs the dx CLI plus the wasm32 target) and uploads it as a release asset, kept separate from the static musl service build so the existing green build is unaffected (the earlier breakage came from building the whole workspace, which pulled the WASM crate into the musl build, so please keep it isolated, ideally a separate job). On the install side we will have the member installer download and unpack that asset into the assets directory whenever Hero OS is enabled, so new installs and updates both get the current desktop. Happy to pair on it. Note the prior revert so the WASM build stays out of the musl build.
Signed-by: mik-tf mik-tf@noreply.invalid
Implemented end to end on the integration line. Release CI publishes the desktop bundle as a release asset through a separate release-web job (it builds the dx tool from source, because the prebuilt dx needs a newer glibc than the builder image has, and it is gated on the binary publish so the static service binaries are never affected). The member installer fetches and unpacks the bundle on a fresh provision, and the binary-update path re-delivers it on Update all instances, so new installs and updates both self-deliver the current desktop. Proven live on a member: deleting the desktop folder, then running the install/update, brings the admin service back up serving the desktop with no manual step. The one mechanical check left is confirming the first full CI run is green (the build runner is slow right now); a bootstrap copy of the bundle is already attached to the rolling release so members are never without it. Follow ups: the islands still need their backends reachable from the desktop (#160 and lhumina_code/home#303), and the Contexts island in particular waits on lhumina_code/hero_osis#66.
Signed-by: mik-tf mik-tf@noreply.invalid
The Hero OS desktop bundle is now built and published by release CI and fetched onto members during provisioning and updates. Recent integration builds are green and members are serving the desktop. Closing as done.