lhumina_code/hero_assistance
0
0
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

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

New issue
Closed
opened 2026-05-07 16:34:09 +00:00 by mik-tf · 1 comment
mik-tf commented 2026-05-07 16:34:09 +00:00
Owner
Copy link

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
mik-tf commented 2026-05-22 12:56:32 +00:00
Author
Owner
Copy link

Status check — substantial divergence from this issue's design

The companion issue #14 landed f81aecc which deleted build-linux.yaml and replaced it with lab-publish.yaml. This changed the publish surface in ways that overlap but do NOT match this issue's acceptance:

Aspect This issue's design #14's actual landing
Workflow file build-linux.yaml (kept + extended) build-linux.yaml deleted + replaced by lab-publish.yaml
Trigger v* tag push push to development (every commit)
Target x86_64-unknown-linux-gnu x86_64-unknown-linux-musl
Asset naming <bin>-linux-amd64 <bin>-linux-musl-x86_64
Tag rotation per-tag v* (immutable) single rolling latest
Channels Releases page + Generic package Releases tag/latest only
svc_install_download compatibility designed for linux-amd64 INCOMPATIBLE with linux-musl-x86_64 suffix
Backfill v0.3.1 required N/A under rolling-latest

Substantive intent is met: binaries are now reachable from a public Forge URL for the --download workflow. Naming-suffix compatibility is broken for the existing svc_install_download helper in hero_skills (Phase 27 / #12 dependency).

Three paths from here:

  1. Update svc_install_download in hero_skills to accept either linux-amd64 (legacy) or linux-musl-x86_64 (canonical going-forward). Aligns with the org-wide rollout per hero_skills#268.
  2. Add a second workflow (or extend lab-publish.yaml) to also publish linux-amd64-suffixed glibc binaries on v* tag pushes, preserving legacy compatibility for unmigrated install modules.
  3. Close as superseded by #14 and file a fresh issue for the naming-suffix work.

Leaving open pending decision. Recommend option 1 (org-wide rollout in any case).

Signed-by: mik-tf mik-tf@noreply.invalid

## Status check — substantial divergence from this issue's design The companion issue #14 landed [`f81aecc`](https://forge.ourworld.tf/lhumina_code/hero_assistance/commit/f81aecc) which **deleted `build-linux.yaml`** and replaced it with `lab-publish.yaml`. This changed the publish surface in ways that overlap but do NOT match this issue's acceptance: | Aspect | This issue's design | #14's actual landing | |---|---|---| | Workflow file | `build-linux.yaml` (kept + extended) | `build-linux.yaml` deleted + replaced by `lab-publish.yaml` | | Trigger | `v*` tag push | `push` to development (every commit) | | Target | `x86_64-unknown-linux-gnu` | `x86_64-unknown-linux-musl` | | Asset naming | `<bin>-linux-amd64` | `<bin>-linux-musl-x86_64` | | Tag rotation | per-tag `v*` (immutable) | single rolling `latest` | | Channels | Releases page + Generic package | Releases `tag/latest` only | | `svc_install_download` compatibility | designed for `linux-amd64` | INCOMPATIBLE with `linux-musl-x86_64` suffix | | Backfill v0.3.1 | required | N/A under rolling-latest | **Substantive intent is met**: binaries are now reachable from a public Forge URL for the `--download` workflow. **Naming-suffix compatibility is broken** for the existing `svc_install_download` helper in hero_skills (Phase 27 / #12 dependency). Three paths from here: 1. **Update `svc_install_download` in hero_skills** to accept either `linux-amd64` (legacy) or `linux-musl-x86_64` (canonical going-forward). Aligns with the org-wide rollout per [hero_skills#268](https://forge.ourworld.tf/lhumina_code/hero_skills/issues/268). 2. **Add a second workflow** (or extend lab-publish.yaml) to also publish `linux-amd64`-suffixed glibc binaries on `v*` tag pushes, preserving legacy compatibility for unmigrated install modules. 3. **Close as superseded** by #14 and file a fresh issue for the naming-suffix work. Leaving open pending decision. Recommend option 1 (org-wide rollout in any case). Signed-by: mik-tf <mik-tf@noreply.invalid>
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
integration
main
v1.0
latest
v0.3.1
v0.2.2
v0.2.1
v0.2.0
v0.1.0
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_assistance#13
No description provided.