feat(service_proc): add --from-ci install path for downloading CI artifacts #193

Merged

mik-tf merged 1 commit from development_mik_release_artifacts_hero_skills_from_ci into development

2026-05-02 13:36:41 +00:00

mik-tf commented

2026-05-02 13:33:52 +00:00

Owner

Summary

First landing in the hero_demo#54 rollout — the consumer side of CI-built artifacts.

Adds --from-ci to service_proc install. Downloads statically-linked binaries from Forgejo Releases instead of running cargo build on the deploy host. Seconds, not minutes; no toolchain dependency on the target.

service_proc install --from-ci                    # latest release
service_proc install --from-ci --version v0.4.4   # pinned tag
service_proc install --from-ci --reset            # force refetch

What this PR does NOT change

The default install path (cargo build) is unchanged. --from-ci is opt-in.
service_proc start still calls install without --from-ci, so existing deploy flows behave identically.
No version bumps, no Cargo changes, no service registration changes.

Where the artifacts come from

hero_proc's .forgejo/workflows/build-linux.yaml has been publishing static-musl binaries on every v* tag push since v0.4.1 (2026-03-25). The pipeline already produces what we need — the hero_demo#54 work was discovering the publisher side already exists; what's been missing is the consumer side. This PR is the consumer.

Verified end-to-end

Against the live v0.4.4 release in a tmpdir HOME:

→ hero_proc: fetching release v0.4.4 from lhumina_code/hero_proc...
  ⤓ hero_proc-linux-amd64
    ✓ /tmp/.../hero/bin/hero_proc
  ⤓ hero_proc_server-linux-amd64
    ✓ /tmp/.../hero/bin/hero_proc_server
  ⤓ hero_proc_ui-linux-amd64
    ✓ /tmp/.../hero/bin/hero_proc_ui
  ✓ hero_proc installed from CI artifacts (release v0.4.4)

All 3 binaries land as ELF 64-bit … static-pie linked, stripped (verified via file).
hero_proc --version reports hero_proc 0.4.4 (verified by running the installed binary).
Re-running --from-ci correctly hits the skip-if-present guard ((pass --reset to refetch)).
--reset correctly forces refetch.
--from-ci against an unknown repo errors cleanly with the resolved API URL in the message.

Design notes

New helpers live in lib.nu under generic names (svc_resolve_release_tag, svc_install_from_ci) so the rest of the easy-tier services (per #54 §Rollout plan) can wire --from-ci with a one-line call.
Asset suffix defaults to linux-amd64 (matches hero_proc's published assets). Repos publishing musl-tagged assets like linux-amd64-musl (per #39's canonical template) override via asset_suffix arg.
No SHA verification yet — Forgejo doesn't publish .sha256 sidecars for hero_proc releases today. TLS handles transport integrity. Cosign / signed sidecars are explicitly out-of-scope per #54 §Storage.
--update and --release are ignored under --from-ci (artifacts are always release-built; no source to pull). Documented in the install docstring.

Followups (separate PRs)

Wire --from-ci into the other easy-tier services (service_router, service_aibroker, service_indexer, service_proxy, service_db, service_osis, service_books, service_biz, service_collab, service_foundry, service_logic, service_archipelagos, service_lib, service_code). One PR per service or one sweep PR.
Wire --from-ci into service_install_all so a whole-stack install can use CI artifacts.
Decide ONNX strategy for hero_voice + hero_embedder (#54 §hard-tier).
Cosmetic rename: hero_proc/.forgejo/workflows/build-linux.yaml → release.yaml to match #39's canonical naming. No functional change.
Close hero_proc#35 — its 'binaries are published manually' premise has been stale since v0.4.1.

Test plan

Unit: svc_resolve_release_tag returns correct tag for latest (v0.4.4) and pinned (v0.4.1).
Unit: svc_resolve_release_tag errors cleanly on unknown repo.
E2E: service_proc install --from-ci --version v0.4.4 downloads, installs, verifies. All 3 binaries are static-pie ELF.
E2E: service_proc install --from-ci --version v0.4.4 re-run hits skip-if-present.
E2E: service_proc install --from-ci --version v0.4.4 --reset forces refetch.
Smoke: installed hero_proc --version reports hero_proc 0.4.4.
Live: deploy on a fresh VM via service_proc install --from-ci, register + start through hero_proc, confirm full lifecycle works (next session, with user OK).

Refs: lhumina_code/hero_demo#54

Signed-off-by: mik-tf

## Summary First landing in the hero_demo#54 rollout — the consumer side of CI-built artifacts. Adds `--from-ci` to `service_proc install`. Downloads statically-linked binaries from Forgejo Releases instead of running `cargo build` on the deploy host. Seconds, not minutes; no toolchain dependency on the target. ```bash service_proc install --from-ci # latest release service_proc install --from-ci --version v0.4.4 # pinned tag service_proc install --from-ci --reset # force refetch ``` ## What this PR does NOT change - The default install path (`cargo build`) is **unchanged**. `--from-ci` is opt-in. - `service_proc start` still calls `install` without `--from-ci`, so existing deploy flows behave identically. - No version bumps, no Cargo changes, no service registration changes. ## Where the artifacts come from hero_proc's `.forgejo/workflows/build-linux.yaml` has been publishing static-musl binaries on every `v*` tag push since [v0.4.1 (2026-03-25)](https://forge.ourworld.tf/lhumina_code/hero_proc/releases/tag/v0.4.1). The pipeline already produces what we need — the `hero_demo#54` work was discovering the publisher side already exists; what's been missing is the consumer side. This PR is the consumer. ## Verified end-to-end Against the live `v0.4.4` release in a tmpdir HOME: ``` → hero_proc: fetching release v0.4.4 from lhumina_code/hero_proc... ⤓ hero_proc-linux-amd64 ✓ /tmp/.../hero/bin/hero_proc ⤓ hero_proc_server-linux-amd64 ✓ /tmp/.../hero/bin/hero_proc_server ⤓ hero_proc_ui-linux-amd64 ✓ /tmp/.../hero/bin/hero_proc_ui ✓ hero_proc installed from CI artifacts (release v0.4.4) ``` - All 3 binaries land as `ELF 64-bit … static-pie linked, stripped` (verified via `file`). - `hero_proc --version` reports `hero_proc 0.4.4` (verified by running the installed binary). - Re-running `--from-ci` correctly hits the skip-if-present guard (`(pass --reset to refetch)`). - `--reset` correctly forces refetch. - `--from-ci` against an unknown repo errors cleanly with the resolved API URL in the message. ## Design notes - New helpers live in `lib.nu` under generic names (`svc_resolve_release_tag`, `svc_install_from_ci`) so the rest of the easy-tier services (per [#54 §Rollout plan](https://forge.ourworld.tf/lhumina_code/hero_demo/issues/54)) can wire `--from-ci` with a one-line call. - Asset suffix defaults to `linux-amd64` (matches hero_proc's published assets). Repos publishing musl-tagged assets like `linux-amd64-musl` (per [#39](https://forge.ourworld.tf/lhumina_code/hero_demo/issues/39)'s canonical template) override via `asset_suffix` arg. - No SHA verification yet — Forgejo doesn't publish .sha256 sidecars for hero_proc releases today. TLS handles transport integrity. Cosign / signed sidecars are explicitly out-of-scope per #54 §Storage. - `--update` and `--release` are ignored under `--from-ci` (artifacts are always release-built; no source to pull). Documented in the install docstring. ## Followups (separate PRs) 1. Wire `--from-ci` into the other easy-tier services (`service_router`, `service_aibroker`, `service_indexer`, `service_proxy`, `service_db`, `service_osis`, `service_books`, `service_biz`, `service_collab`, `service_foundry`, `service_logic`, `service_archipelagos`, `service_lib`, `service_code`). One PR per service or one sweep PR. 2. Wire `--from-ci` into `service_install_all` so a whole-stack install can use CI artifacts. 3. Decide ONNX strategy for hero_voice + hero_embedder (#54 §hard-tier). 4. Cosmetic rename: `hero_proc/.forgejo/workflows/build-linux.yaml` → `release.yaml` to match #39's canonical naming. No functional change. 5. Close [hero_proc#35](https://forge.ourworld.tf/lhumina_code/hero_proc/issues/35) — its 'binaries are published manually' premise has been stale since v0.4.1. ## Test plan - [x] Unit: `svc_resolve_release_tag` returns correct tag for `latest` (`v0.4.4`) and pinned (`v0.4.1`). - [x] Unit: `svc_resolve_release_tag` errors cleanly on unknown repo. - [x] E2E: `service_proc install --from-ci --version v0.4.4` downloads, installs, verifies. All 3 binaries are static-pie ELF. - [x] E2E: `service_proc install --from-ci --version v0.4.4` re-run hits skip-if-present. - [x] E2E: `service_proc install --from-ci --version v0.4.4 --reset` forces refetch. - [x] Smoke: installed `hero_proc --version` reports `hero_proc 0.4.4`. - [ ] Live: deploy on a fresh VM via `service_proc install --from-ci`, register + start through hero_proc, confirm full lifecycle works (next session, with user OK). Refs: https://forge.ourworld.tf/lhumina_code/hero_demo/issues/54 Signed-off-by: mik-tf

mik-tf added 1 commit

2026-05-02 13:33:52 +00:00

feat(service_proc): add --from-ci install path for downloading CI artifacts

Build and Publish Skills / build-and-publish (pull_request) Successful in 4s

Details

b505655ae7

Adds an opt-in install path that downloads statically-linked binaries from
Forgejo Releases instead of running cargo build on the deploy host. Seconds,
not minutes; no toolchain dependency on the target.

  service_proc install --from-ci                    # latest release
  service_proc install --from-ci --version v0.4.4   # pinned tag
  service_proc install --from-ci --reset            # force refetch

Default path (cargo build) is unchanged — --from-ci is opt-in. --update and
--release are ignored under --from-ci (artifacts are always release-built).

New helpers in lib.nu:
- svc_resolve_release_tag: "latest" → resolves via Forgejo API, else verbatim
- svc_install_from_ci: download + verify + install loop, mirrors svc_install's
  contract (sudo, --reset skip-if-present, same destination dir)

Verified end-to-end against the published v0.4.4 release: 3 static-pie ELF
binaries land under HOME/hero/bin and the resulting hero_proc --version
reports the correct version.

This is the consumer side of hero_demo#54 — the hero_proc CI release pipeline
under .forgejo/workflows/build-linux.yaml has been publishing static-musl
binaries since v0.4.1 (2026-03-25); this lands the install path that consumes
them.

Refs: lhumina_code/hero_demo#54
Refs: lhumina_code/hero_proc#35
Signed-off-by: mik-tf <logismos@protonmail.ch>