chore(ops): Phase 27-prep — Forgejo Releases page parity (hero_embedder --download pattern) + cut v0.4.0 Hero OS integration milestone #13

New issue

Open

opened 2026-05-07 16:34:09 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-05-07 16:34:09 +00:00

Owner

Why

The customer-readiness story needs a working service_hero_assistance install --download path (Phase 27 / #12). That helper consumes Forgejo Releases page binary assets (the hero_embedder pattern) — but our current CI publishes only to the Generic package registry. 6 tags pushed (v0.1.0..v0.3.1), 0 Forgejo Releases. Phase 27 would fail today even after we ship the install module.

Reference impl: lhumina_code/hero_embedder v0.2.0-rc1 — 12 binary assets attached to the Releases page, naming convention <bin>-<target-triple>.

Issue #12 body's claim of "publishes to both Releases page AND Generic registry" is stale/aspirational; reality is Generic-only.

Order

Phase 27-prep — must complete before Phase 27 (#12). Can run in parallel with Phases 24/25/26; recommended slot is the interlude between Phase 26 and Phase 27 once the customer SPA island work lands. v0.4.0 milestone tag waits until all four integration phases (24-27) are engineering-complete.

What

A. CI workflow update — attach assets to Forgejo Releases page

Update .forgejo/workflows/build-linux.yaml to mirror hero_embedder's release step:

On v* tag push, after building binaries, create-or-update a Forgejo Release at that tag and upload the 3 binaries as Release assets.
Naming convention <bin>-linux-amd64 (matches svc_install_download exactly).
Keep the existing Generic package publish step as backup channel (hero_embedder publishes to both — preserves current behavior, additive change).

Reference: forge-release-workflow skill canonical recipe; cross-check against hero_embedder/.forgejo/workflows/.

B. Backfill existing tags

v0.1.0, v0.2.0, v0.2.1, v0.2.2, v0.3.0, v0.3.1 are pushed but have no Releases page. Two options (decide in step 1):

B1: Re-run CI for each tag (push tag deletion + re-push, or trigger workflow manually) — exercises the new flow on every tag.
B2: Backfill only v0.3.1 (latest); older tags stay Generic-only — keeps the scope minimal.

Recommend B2 for blast-radius reasons; B1 is over-engineering past tags.

C. v0.4.0 milestone tag

Once Phases 24-27 all land, bump buildenv.sh VERSION to 0.4.0, tag v0.4.0, let CI publish. This is the "Hero OS integration complete" marker. Distinct from any v1.0.0 tag (still customer-gated by #7).

Acceptance

.forgejo/workflows/build-linux.yaml publishes binaries to both Forgejo Releases page and Generic package registry on every v* tag
Forgejo Releases page lists at least v0.3.1 with 3 binary assets attached
Asset naming <bin>-linux-amd64 confirmed compatible with svc_install_download helper (parity with hero_embedder)
After Phases 24/25/26/27 land: buildenv.sh VERSION → 0.4.0; v0.4.0 tag pushed; CI publishes; release page populated
Issue #12 body updated to remove stale "publishes to both" claim once reality matches
No regressions to Generic package publish path (s32 invariant)
All 225 native tests still pass

Files to touch

.forgejo/workflows/build-linux.yaml — add Forgejo Releases publish step
buildenv.sh — VERSION bump (only at v0.4.0 cut, not at workflow-fix time)
(no source code changes; ops/CI only)

Out of scope

Backfilling v0.1.0..v0.3.0 to Releases page (B1) unless trivial
Cross-arch builds (aarch64 etc.) — stay on linux-amd64 per current CI
v1.0.0 tag — gated separately by #7 customer-readiness

References

Skill forge-release-workflow — canonical Forgejo release-on-tag recipe
Skill forge_release — release management
Reference impl: lhumina_code/hero_embedder v0.2.0-rc1 Releases page (12 assets, 5 binaries × 2 arches + onnxruntime)
Reference impl: lhumina_code/hero_skills/nutools/modules/services/service_collab.nu — svc_install_download consumer
s32 introduced the workflow (issue #6, closed): #6
Phase 27 (consumes this): #12

## Why The customer-readiness story needs a working `service_hero_assistance install --download` path (Phase 27 / #12). That helper consumes **Forgejo Releases page** binary assets (the hero_embedder pattern) — but our current CI publishes only to the Generic package registry. **6 tags pushed (v0.1.0..v0.3.1), 0 Forgejo Releases.** Phase 27 would fail today even after we ship the install module. Reference impl: `lhumina_code/hero_embedder` v0.2.0-rc1 — 12 binary assets attached to the Releases page, naming convention `<bin>-<target-triple>`. Issue #12 body's claim of "publishes to both Releases page AND Generic registry" is stale/aspirational; reality is Generic-only. ## Order **Phase 27-prep — must complete before Phase 27 (#12).** Can run in parallel with Phases 24/25/26; recommended slot is the interlude between Phase 26 and Phase 27 once the customer SPA island work lands. v0.4.0 milestone tag waits until all four integration phases (24-27) are engineering-complete. ## What ### A. CI workflow update — attach assets to Forgejo Releases page Update `.forgejo/workflows/build-linux.yaml` to mirror hero_embedder's release step: - On `v*` tag push, after building binaries, create-or-update a Forgejo Release at that tag and upload the 3 binaries as Release assets. - Naming convention `<bin>-linux-amd64` (matches `svc_install_download` exactly). - Keep the existing Generic package publish step as backup channel (hero_embedder publishes to both — preserves current behavior, additive change). Reference: `forge-release-workflow` skill canonical recipe; cross-check against `hero_embedder/.forgejo/workflows/`. ### B. Backfill existing tags v0.1.0, v0.2.0, v0.2.1, v0.2.2, v0.3.0, v0.3.1 are pushed but have no Releases page. Two options (decide in step 1): - **B1**: Re-run CI for each tag (push tag deletion + re-push, or trigger workflow manually) — exercises the new flow on every tag. - **B2**: Backfill only v0.3.1 (latest); older tags stay Generic-only — keeps the scope minimal. Recommend B2 for blast-radius reasons; B1 is over-engineering past tags. ### C. v0.4.0 milestone tag Once Phases 24-27 all land, bump `buildenv.sh` VERSION to `0.4.0`, tag `v0.4.0`, let CI publish. This is the "Hero OS integration complete" marker. Distinct from any v1.0.0 tag (still customer-gated by #7). ## Acceptance - [ ] `.forgejo/workflows/build-linux.yaml` publishes binaries to **both** Forgejo Releases page and Generic package registry on every `v*` tag - [ ] Forgejo Releases page lists at least v0.3.1 with 3 binary assets attached - [ ] Asset naming `<bin>-linux-amd64` confirmed compatible with `svc_install_download` helper (parity with hero_embedder) - [ ] After Phases 24/25/26/27 land: `buildenv.sh` VERSION → `0.4.0`; `v0.4.0` tag pushed; CI publishes; release page populated - [ ] Issue #12 body updated to remove stale "publishes to both" claim once reality matches - [ ] No regressions to Generic package publish path (s32 invariant) - [ ] All 225 native tests still pass ## Files to touch - `.forgejo/workflows/build-linux.yaml` — add Forgejo Releases publish step - `buildenv.sh` — VERSION bump (only at v0.4.0 cut, not at workflow-fix time) - (no source code changes; ops/CI only) ## Out of scope - Backfilling v0.1.0..v0.3.0 to Releases page (B1) unless trivial - Cross-arch builds (aarch64 etc.) — stay on `linux-amd64` per current CI - v1.0.0 tag — gated separately by #7 customer-readiness ## References - Skill `forge-release-workflow` — canonical Forgejo release-on-tag recipe - Skill `forge_release` — release management - Reference impl: `lhumina_code/hero_embedder` v0.2.0-rc1 Releases page (12 assets, 5 binaries × 2 arches + onnxruntime) - Reference impl: `lhumina_code/hero_skills/nutools/modules/services/service_collab.nu` — `svc_install_download` consumer - s32 introduced the workflow (issue #6, closed): https://forge.ourworld.tf/lhumina_code/hero_assistance/issues/6 - Phase 27 (consumes this): https://forge.ourworld.tf/lhumina_code/hero_assistance/issues/12