[ci] WASM bundle published to pkg registry only — no Release assets, --from-ci blind to hero_os #125

New issue

Open

opened 2026-05-04 01:44:59 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-05-04 01:44:59 +00:00

Owner

Phase 3 scope (Hero CI roadmap, hero_demo#54)

release.yaml builds the WASM bundle correctly via dx build --release, packages it as hero_os-web-<version>.tar.gz, then publishes to package registry only (/api/packages/.../generic/hero_os/<v>/...). Never creates a Forgejo Release nor uploads to /api/v1/repos/.../releases/.../assets.

Same root cause as binary cluster A (hero_biz#13, hero_books#118, hero_browser#16, hero_foundry#26). Fix shape mirrors hero_proc's build-linux.yaml Release-asset upload steps, adapted for a single tarball asset.

State

Tags: v0.1.1, v0.1.2, v0.1.3 ✓
Releases: none
Package registry: hero_os 0.1.2 / 0.1.3 / dev ✓ (proves CI runs and publish succeeds — just to wrong destination)

Consumer side (additional gap)

service_os.nu line 26 documents the install path as "fetch source, cargo build, copy binaries" — i.e. ~25 min cold dx build --release on every VM. No --from-ci path exists for WASM artifacts (the existing svc_install_from_ci helper is binary-shaped: single file → ~/hero/bin/, not tarball → extract → ~/hero/share/hero_os/public/).

A new helper svc_install_wasm_from_ci (or extension to the existing one) is needed in hero_skills/tools/modules/services/lib.nu before this issue's producer fix delivers user-visible value.

Recommended fix (producer side, this issue)

Adapt hero_proc's pattern:

After "Package release" step, add Create Release (race-tolerant POST → GET fallback).
Add Upload Release Assets uploading hero_os-web-<v>.tar.gz to /api/v1/repos/.../releases/<id>/assets.
Keep "Publish to packages" as secondary mirror.

Effort

~1-2 h for the workflow producer side. Consumer-side helper + service_os.nu rewiring tracked separately (hero_skills issue, TBD).

ROI

Highest-leverage piece in the entire Hero CI roadmap: every demo VM and every contributor onboarding hits this. Sub-minute fresh-deploy is unblocked entirely by completing this + the consumer helper.

## Phase 3 scope (Hero CI roadmap, [hero_demo#54](https://forge.ourworld.tf/lhumina_code/hero_demo/issues/54)) `release.yaml` builds the WASM bundle correctly via `dx build --release`, packages it as `hero_os-web-<version>.tar.gz`, then publishes to **package registry only** (`/api/packages/.../generic/hero_os/<v>/...`). Never creates a Forgejo Release nor uploads to `/api/v1/repos/.../releases/.../assets`. Same root cause as binary cluster A ([hero_biz#13](https://forge.ourworld.tf/lhumina_code/hero_biz/issues/13), [hero_books#118](https://forge.ourworld.tf/lhumina_code/hero_books/issues/118), [hero_browser#16](https://forge.ourworld.tf/lhumina_code/hero_browser/issues/16), [hero_foundry#26](https://forge.ourworld.tf/lhumina_code/hero_foundry/issues/26)). Fix shape mirrors hero_proc's `build-linux.yaml` Release-asset upload steps, adapted for a single tarball asset. ## State - Tags: v0.1.1, v0.1.2, v0.1.3 ✓ - Releases: **none** - Package registry: `hero_os 0.1.2 / 0.1.3 / dev` ✓ (proves CI runs and publish succeeds — just to wrong destination) ## Consumer side (additional gap) `service_os.nu` line 26 documents the install path as *"fetch source, **cargo build**, copy binaries"* — i.e. ~25 min cold `dx build --release` on every VM. No `--from-ci` path exists for WASM artifacts (the existing `svc_install_from_ci` helper is binary-shaped: single file → `~/hero/bin/`, not tarball → extract → `~/hero/share/hero_os/public/`). A new helper `svc_install_wasm_from_ci` (or extension to the existing one) is needed in `hero_skills/tools/modules/services/lib.nu` before this issue's producer fix delivers user-visible value. ## Recommended fix (producer side, this issue) Adapt hero_proc's pattern: 1. After "Package release" step, add **Create Release** (race-tolerant POST → GET fallback). 2. Add **Upload Release Assets** uploading `hero_os-web-<v>.tar.gz` to `/api/v1/repos/.../releases/<id>/assets`. 3. Keep "Publish to packages" as secondary mirror. ## Effort ~1-2 h for the workflow producer side. Consumer-side helper + service_os.nu rewiring tracked separately (hero_skills issue, TBD). ## ROI Highest-leverage piece in the entire Hero CI roadmap: every demo VM and every contributor onboarding hits this. Sub-minute fresh-deploy is unblocked entirely by completing this + the consumer helper.