story: CI builds all binaries & naming convention used #212
mik-tf
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?
Outcome
Summary
Hero's CI release artifacts use three different naming conventions across 9 repos today, and several asset names misrepresent what's actually inside them. Standardize on the full Rust target triple convention used by ripgrep, fd, bat, starship, cargo-binstall, eza, etc. —
x86_64-unknown-linux-musl,x86_64-unknown-linux-gnu,aarch64-unknown-linux-gnu, etc. — naming each asset for whatever its workflow actually builds, not what we wish it built.This is the workspace-wide naming standard, distinct from the
--from-cirollout itself (hero_demo#54).Non-goal: this issue does NOT force every binary onto musl. If a workflow builds glibc, the asset gets a
-gnusuffix and is honestly labeled. The convention is the shape (target triple), not a libc mandate. A separate issue can later argue "should everything migrate to musl" — that's an independent question.Current state — three conventions, several mislabeled assets
linux-amd64(kubectl/gh shape)hero_proc-linux-amd64linux-amd64-musl(Hero hybrid)hero_router-linux-amd64-muslPlus inconsistent arm64 handling: hero_browser and hero_db cross-compile arm64 with gnu but ship them as
linux-arm64— silently glibc, not musl, no signal in the name.Asset names don't reliably reflect what's inside. Inspecting each workflow's actual
cargo build --target ...shows several mismatches:hero_proc-linux-amd64is musl (workflow usesx86_64-unknown-linux-musl)hero_books-linux-amd64is gnu (workflow usesx86_64-unknown-linux-gnu)hero_db-linux-arm64is gnu (workflow usesaarch64-unknown-linux-gnu)hero_browser-linux-arm64is gnu (same)This is the core problem the issue addresses: naming should tell the truth about what the binary is.
Decision: full Rust target triple, honest about libc
Why
cargo-binstallintegration. Anything published with target-triple naming auto-discovers viacargo binstall hero_proconce Hero binaries are on crates.io.x86_64-apple-darwin,aarch64-apple-darwin, future Windows targets.linux-amd64hides that. Target triple makes it visible.All future Hero binary releases use this convention
This applies retroactively to:
<bundle>-wasm32-unknown-unknown.tar.gzor similar — settle in the WASM-rollout subthread of #54.Migration plan for existing 9 repos — all pure rename, no rebuilds
Forgejo supports
PATCH /api/v1/repos/{owner}/{repo}/releases/{id}/assets/{attachment_id}with{"name": "<new-name>"}. The binary bytes are unchanged; only the asset's name attribute updates. No re-tag, no rebuild, no version bump needed.Per-repo migration table (rename existing assets to honestly reflect what they are):
hero_proc-linux-amd64(×3)hero_proc-x86_64-unknown-linux-muslhero_router-linux-amd64-muslhero_router-x86_64-unknown-linux-muslhero_proxy_*-linux-amd64-musl(×3)hero_proxy_*-x86_64-unknown-linux-muslhero_db_*-linux-amd64(×3)hero_db_*-x86_64-unknown-linux-muslhero_db_*-linux-arm64(×3)hero_db_*-aarch64-unknown-linux-gnuhero_indexer_*-linux-amd64-musl(×3)hero_indexer_*-x86_64-unknown-linux-muslhero_aibroker_*-linux-amd64-musl(×4)hero_aibroker_*-x86_64-unknown-linux-muslhero_*-linux-amd64-musl(×4)hero_*-x86_64-unknown-linux-muslhero_books_*-linux-amd64(×5)hero_books_*-x86_64-unknown-linux-gnuhero_browser_*-linux-amd64(×3)hero_browser_*-x86_64-unknown-linux-muslhero_browser_*-linux-arm64(×3)hero_browser_*-aarch64-unknown-linux-gnuNote —
hero_indexerandhero_aibrokeralso publish a gnu duplicate today (linux-amd64alongsidelinux-amd64-musl). Two clean options at rename time:*-x86_64-unknown-linux-muslAND*-x86_64-unknown-linux-gnu— operator picksservice_*.numodules pull only the-muslshape today)Old
--from-cikeeps working (atomic per-repo flip)The naming change does NOT break the existing 9 services already wired with
--from-ci. Two safety properties:svc_install_from_cibuilds the asset URL from the suffix string passed in. As long as the rename + the consumer-suffix update happen together (per-repo), there's no broken window.Recommended per-repo flip order (atomic):
build-linux.yaml/release.yaml) so the next tag-cut produces assets with the new names directly.service_X.nuconsumer to pass the new suffix tosvc_install_from_ci.service_X install --from-ci --reseton heroci to confirm the new name resolves.Total effort: ~30 min/repo × 9 repos ≈ 4-5 h. Can ship one repo at a time, no big-bang merge.
Cross-refs
--from-cirollout (parent)Out of scope
--from-cirollout itself (covered in #54).Signed-off-by: mik-tf
Strategic context (added 2026-05-06 session 68)
This binary-rollout arc is the first leg of a three-leg tripod that makes Hero deployable as an end-user product:
End state once all three land plus the planned auth arc:
hero_routerexposes/install/<name>, the bootstrap collapses to two binaries (hero_router+hero_proc), and from any browser an owner installshero_os+ apps via the existingservice install --downloadpath. The Store island inhero_archipelagosalready has TODO comments for the dynamic catalog. None of that final wiring blocks; this issue is the precondition — every service must have a published artifact before an in-browser install is possible.[infra][P2] standardize CI release-asset naming on Rust target triples (x86_64-unknown-linux-musl)to [infra][P2] standardize CI release-asset naming on Rust target triples (honest libc per repo)mik-tf referenced this issue from lhumina_code/hero_demo2026-05-04 20:33:56 +00:00
[infra][P2] standardize CI release-asset naming on Rust target triples (honest libc per repo)to story: CI builds all binaries & naming convention usedClosed by session 64 (2026-05-06).
All 10 producer repos in the migration table updated atomically — workflow files renamed, 39 release assets flipped via the Forgejo asset-PATCH endpoint (pure metadata, no rebuilds), consumer-side
service_*.nusuffixes updated in lockstep, all PRs squash-merged.Migration table outcome
linux-amd64-musl→x86_64-unknown-linux-musllinux-amd64(musl!) →x86_64-unknown-linux-musl✓ honestlinux-amd64-musl→x86_64-unknown-linux-musllinux-amd64{,-arm64}→x86_64-unknown-linux-musl+aarch64-unknown-linux-gnu✓ honest mixed-libclinux-amd64-musl→x86_64-unknown-linux-musllinux-amd64-musl→x86_64-unknown-linux-musl(bothrelease.yamlandbuild-linux.yamlupdated)linux-amd64-musl→x86_64-unknown-linux-musllinux-amd64(gnu!) →x86_64-unknown-linux-gnu✓ honest gnulinux-amd64{,-arm64}→x86_64-unknown-linux-musl+aarch64-unknown-linux-gnu✓ honest mixed-libclinux-amd64(gnu!) →x86_64-unknown-linux-gnu✓ honest gnu (not in the original migration table — added during the rename arc audit)Consumer-side: hero_skills PR #217 merged at
877217d— 10 commits, one per service module.Honest-libc reveals
Three repos had been mislabeling what they shipped:
x86_64-unknown-linux-muslbut called the assetlinux-amd64— fixed.x86_64-unknown-linux-gnubut called the assetlinux-amd64— fixed.x86_64-unknown-linux-gnu(workflow runscargo build --releasewithout--targetinsideghcr.io/despiegk/builder:latest) but called the assetlinux-amd64— fixed.Mixed-libc reveals:
linux-arm64.linux-arm64.After this work, every shipping Hero binary's release-asset name honestly reflects its real ABI.
Verification
All 10 services smoke-tested on heroci against
hero_skills @ 877217d:Process notes
HTTP 201, all bytes preserved, all new URLs serve200while old URLs return404.git worktreeoutside the main checkouts to protect feature branches from a periodic branch-cleanup agent. After all PRs merged, worktrees + local feature branches were cleaned up.Closing — convention is now uniform across the workspace, every future tag-cut publishes target-triple-named assets directly, and there are no open follow-ups blocking this issue.
mik-tf referenced this issue from lhumina_code/hero_demo2026-05-06 16:10:25 +00:00
Status update — home#212 reopened after thorough audit (session 64)
Reopened after the user pushed back on premature closure. The issue's stated outcome is "all repo's in lhumina code follow convention AND build all binaries" — the rename arc closed the first half (naming convention), but the second half (every relevant repo actually publishing CI artifacts) is still open work.
Where we actually are
Naming convention (first half) — ✅ done for shipping repos. Session 64's rename arc flipped 39 release assets across 10 repos. All 18 Hero repos that currently publish CI artifacts now use
<bin>-<full-rust-target-triple>shape. Confirmed by smoke-testing every one of them on heroci againsthero_skills @ 877217d:Build-all-binaries (second half) — ❌ not done. 11 repos still missing CI artifacts.
Bucket C: 7 repos with
service_*.nuconsumer wiring but NO published releaseAll 7 are actively developed (commits within ~1 week). Cargo workspaces. Need producer-side
build-linux.yamladded + first tag cut.build.yamlonly (CI builds, no release)build-linux.yaml. Demo-critical (AI orchestrator).build-linux.yaml+build-macos.yamlexistservice_hero_do+service_runner_rhai).Bucket D: 4 repos shipping binaries but NOT in
nutools/service_*.nuAND with old-shape namingFound during the broader org audit — these are off-radar from the rename arc:
hero_compute-linux-amd64-musl,hero_compute-linux-arm64-gnu,hero_compute_explorer-...heroledger-linux-x64,heroledger-relayer-linux-x64hero_prefix;x64notamd64). Investigate first — might be third-party or exempt.hero_sync{,_server,_ui}-linux-amd64-musltfsporesd-linux-amd64-muslUniverse summary
nutools(Category A — done).nutoolsradar and old-shape names (Bucket D — needs rename + nutools wiring decision).Estimated remaining work
Conclusion
Issue stays open. Naming-convention half is done; the build-all-binaries half is the next chunk of work. Reasonable next session targets a single Bucket C repo (e.g.
hero_lib_rhaisince the workflow already exists — just need the first tag) for a smaller win, orhero_agentfor the highest-leverage demo improvement.Session 65 —
hero_lib_rhaishipped (Bucket C, item 1)Progress: 18/29 → 19/29 (66% complete).
What landed
Producer side (
lhumina_code/hero_lib_rhai) — 6 squash-merged PRs:74ae6f011651daab985c9(deleted upstream branch)65e39706efb0992f788c576cc903Consumer side (
lhumina_code/hero_skills):3c18649— service_hero_do + service_runner_rhai suffix flip + dispatcher gap fix (hero_do install + runner_rhai install/start aliases)Tag shipped:
v0.1.0-rc6with 4 release assets (~23MB total):Smoke (heroci.gent01.grid.tf)
Notable findings + follow-up debt filed
crates/ai_rhaifor the broker-firstherolib_airewrite. Blocks lifting the rev-pin from PR #15. Child of home#219.test-linuxfails onMISSING: hero_proc. Pre-existing, not session 65 regression. Sister of hero_lib#134.Architectural note
hero_lib_rhaijoins D-05's gnu bucket for the same reason ONNX services did: native deps (rusb, pci-info, virtiofsd via herolib_mos/herolib_virt) need glibc dynamic linkage. Pattern is established — future native-dep services should default to gnu from day one.Universe state
hero_lib_rhai): ✓ done this sessionhero_agent,hero_collab,hero_office,hero_planner,hero_logic,hero_mail): pending (~6 sessions @ 1-3h each)hero_compute,hero_ledger,hero_sync,hero_tfspores): pending (1 batched session)Session 66 close —
hero_agentshipped via pure-musl pipeline → 19/29 → 20/29 (69%)What landed
First release pipeline for
hero_agent(Bucket C item 2). User constrained matrix to x86 only — no aarch64. Pure-musl bucket (no native deps; rustls-tls only).Producer:
e7dc67d— portbuild-linux.yamlmirroringhero_proc/build-linux.yamlbyte-for-byte except sources$BINARIESfrombuildenv.sh.0b577a9— install rustc 1.93 explicitly (builder image ships 1.92, Cargo.toml pins 1.93). Mirrors the existingbuild.yamltest workflow's toolchain step.v0.1.0-rc2: 3 assets (~22 MB), all<bin>-x86_64-unknown-linux-musl, statically-linked PIE.Consumer:
f7758fc— flipservice_agent.nusuffixlinux-amd64→x86_64-unknown-linux-musl+ dispatcher--download/--versionforwarding for[agent install]and--downloadfor[agent start].Heroci smoke:
service agent install --download --resetfetched all 3 assets, ELF-verified static-musl, all binaries execute cleanly.Why this was 2 rcN vs session-65's 6
hero_agent has no native deps. The session-65 playbook items 17–20 prevented an entire class of failures (toolchain target-add, branch rot, gnu pivot, link deps); only debt that surfaced was rustc 1.92 vs 1.93 mismatch. Pre-flight (cargo metadata, cargo fmt, cargo clippy, local musl dry-build) all clean.
Playbook addition (item 22)
Local pre-flight caught a defect that
--workspacemasks: hero_agent's[[bin]] name = "hero_agent"lives incrates/hero_agent_daemon/, notcrates/hero_agent/.cargo build -p hero_agent(lib crate) produces no binary. The session-65 playbook item 18 ("scope cargo build to -p shipped binaries") would have silently dropped the binary if applied here. Default to--workspaceunless a non-shipped crate pulls native C deps.Coverage status
Next session (67):
hero_collab(Bucket C item 3) — already running on demo, no CI yet. Expected pure-musl (will confirm via Cargo.toml audit); should follow hero_agent's template directly.Details:
sessions/66.yml.Session 67 — Bucket C item 3 closed (
hero_collabv0.5.0-rc1)Coverage 20/29 → 21/29 (72%).
Producer arc (hero_collab#51
0e91871) — single PR, 3 commits:cargo fmt --all(50 files, mechanical) and 16 clippy fixes (doc_lazy_continuation×5, collapsible_if×4 via 2024 if-let chains, dead_code on serde fixtures, type_complexity, assert_eq-with-bool×2, manual split_once, redundant guard) so the workspace satisfies the pre-merge gate..forgejo/workflows/build-linux.yamlmirroring the canonical pure-musl pipeline (hero_proc / hero_agent shape).-p hero_collab_server -p hero_collab_ui -p hero_collab(not--workspace):hero_collab_appis the Dioxus WASM frontend and currently fails its host-linux compile against the latesthero_archipelagosdevelopment(use_focus_pollrename +IslandContextfield drift) — separate archipelago refactor, not a release blocker.hero_collab_examplesis a test crate.Tag
v0.5.0-rc1shipped 3 assets, first try, zero fix-forwards (~34 MB raw / ~22 MB stripped):hero_collab-x86_64-unknown-linux-musl(8.0 MB)hero_collab_server-x86_64-unknown-linux-musl(14.2 MB)hero_collab_ui-x86_64-unknown-linux-musl(11.5 MB)Consumer arc (hero_skills#223
15f6cf3) — 3-line diff:service_collab.nu: download suffixlinux-amd64→x86_64-unknown-linux-musl.dispatcher.nu: forward--download/--versionon[collab install]and--downloadon[collab start](closes the same gap fixed for 19 other services in sessions 62–66).Heroci smoke green:
service collab install --download --resetfetched all 3 assets, ELF-verified static-pie musl (stripped),hero_collab_server --versionreportshero_collab 0.5.0,hero_collab_uistarts cleanly.Follow-up debt filed: hero_collab#52 — repo has no PR-time CI workflow today (
.forgejo/workflows/had only the new release pipeline). Other Hero repos runcargo build+cargo teston push viabuild.yaml/ci.yml. Deferred to a separate batched arc that can be repeated cleanly across the remaining Bucket C items.Pure-musl bucket continues to extend cleanly — same shape as session 66 (hero_agent). 1 rcN attempt vs session-65 hero_lib_rhai's 6, because hero_collab has no native deps (rustls, rusqlite-bundled) and no
rust-versionpin. The only friction was pre-existing fmt/clippy debt and one upstream-API-drift wasm crate to scope out.Remaining buckets:
hero_office,hero_planner,hero_logic,hero_mail). Recommended next: investigatehero_officefirst (OnlyOffice integration — confirm whether it ships a Hero binary or wraps Docker before committing).hero_compute,hero_ledger,hero_sync,hero_tfspores) — candidate for a single batched session.Session 68 —
hero_officev0.1.0-rc1 shipped (22/29 = 76%)Coverage: 21/29 → 22/29 (76%).
Producer
4b7470e—cargo fmt --all, 2 clippy fixes (collapsible if-let, doc list paragraph break),.forgejo/workflows/build-linux.yamlmirroring hero_collab template, reqwest workspace dep flipped todefault-features=false, features=[json, rustls-tls](drops 422 Cargo.lock lines from native-tls/openssl-sys chain).actions/checkout@v4transient flake (run #24959 push event failed in 1m15s — logs inaccessible on private repo).workflow_dispatchretry on the same tag (run #24961) succeeded clean in 1m18s. No fix-forward, no code change.Consumer A — suffix flip + dispatcher gap
f6e6e17— fliplinux-amd64→x86_64-unknown-linux-musl, forward--download/--versionfor[office install]and--downloadfor[office start]indispatcher.nu.Consumer B — private-repo auth fix (architectural surprise)
hero_officeis the only private non-archived repo inlhumina_code/. Its release assets 404 anonymously while every other Hero stack repo serves them publicly.c28ba16—svc_forge_auth_argsinlib.nuforwards$env.FORGEJO_TOKENas Authorization header on private-repo metadata + asset downloads. Public-repo behaviour unchanged (empty header list when no token).proc secret get) is tracked under #222 / #225.Heroci smoke
All 3 binaries: ELF 64-bit LSB pie executable, x86-64, static-pie linked, stripped.
Strategic triage filed this session
The auth-fix conversation surfaced META-rule violations across the stack. Filed:
This issue body patched with strategic-context section pointing forward to #225 + #226 + the end-state vision (tripod → router-as-installer → 2-binary bootstrap → end-user product loop).
Playbook addition (item 26)
Private-repo
--downloadrequires FORGEJO_TOKEN in operator's env. Pre-flight: check repo'sprivateflag via/api/v1/repos/<loc>. If true, document the requirement in consumer PR + ensure operator can export it. Long-term: home#222 replaces this$envread withproc secret get.Remaining (7 repos to 29/29)
Pinned next
Session 69 =
hero_planner(Bucket C item 5) — pure-musl pattern repeat per session 67/68 template. Expect 1 rcN, ~30 min.Session 69 update — Bucket C item 5 closed
Coverage: 22/29 → 23/29 (79%).
Shipped:
hero_plannerv0.1.0-rc1 — first release pipeline. 3 musl assets (hero_planner,hero_planner_ui,hero_planner_web) at target-triple naming.Producer PR: hero_planner#4
13ae388— single PR bundled cargo fmt across 8 files (~1.2k lines), module-scope#![allow(clippy::too_many_arguments)]onhero_planner_lib/src/store.rs(10 CRUD methods, 8-11 args each — entity-with-many-fields shape), backfill of 2 missing args at thecost_createtest call site (test stale vs upstream commitc7cd110), and.forgejo/workflows/build-linux.yamlmirroring hero_office's pure-musl template with two adjustments:--workspacebuild (5 members, all pure-Rust, no native deps), explicitrustup toolchain install 1.93(rust-toolchain.toml pin; mirrors session 66 hero_agent fix).Consumer: no PR needed.
service_planner.nuwas already wired with--download+x86_64-unknown-linux-muslsuffix during session 64's home#212 sweep. dispatcher.nu also pre-wired. Smallest Bucket C session yet (~45 min) for that reason.1 rcN, 1 fix-forward: run #1 push failed at Upload Release Assets (curl exit 22, "Release ID: null") —
FORGEJO_TOKENrepo-secret missingwrite:repositoryscope. Third recurrence after sessions 57 (whiteboard) and 60 (editor). Token refreshed out-of-band;workflow_dispatchretry on the same v0.1.0-rc1 tag (run #2) succeeded end-to-end.Cleanup: workflow_dispatch on a tag also fires the push trigger, so each binary uploaded twice (15s apart). Cleaned up via DELETE on 3 older attachment IDs. Final state: 3 assets.
Heroci smoke green:
service planner install --download --reset --version v0.1.0-rc1→ all 3 assets land at/root/hero/bin/, ELF static-pie musl,hero_planner --helpclean, UI/web bind their respective sockets and SIGTERM cleanly.Spec drift surfaced (out-of-scope): commit
c7cd110hand-editedcrates/hero_planner_sdk/src/openrpc.client.generated.rsto addkindtoRequirementCreateInput/RequirementUpdateInput, butopenrpc.jsondoes NOT listkindin those params. Per D-03 the fix is at the spec layer; reverted snapshot to HEAD in PR #4, called out in the PR body.Remaining: 6 repos (Bucket C: hero_logic, hero_mail; Bucket D: hero_compute, hero_ledger, hero_sync, hero_tfspores).
Next session (70): Bucket C item 6 —
hero_logic.development—development_crate_layoutis the de-facto Hero branch (24 commits ahead ofdevelopment/master) #46Tracked alongside home#230 — Phase 4 of #230 audits the 20 s77 tags for target-triple-named release assets, which feeds into closing this issue.
Reshape under D-07 + D-08 — keeping open, scope changes.
Two recent decisions reshape what this issue tracks without closing it:
D-07 (session 79):
aarch64-unknown-linux-gnuis dropped from CI matrices going forward. Producer PRs archive the two-arch workflow as<name>.yaml.archived-aarch64and ship an x86-only canonical. Reversible per repo, not deleted.D-08 (session 80):
hero_builderis the canonical build orchestrator going forward; per-repobuildenv.sh+ ad-hoccargo build --workspace --releasedeprecated. Producer naming flows fromhero_builderplatform labels (linux-musl-x86_64,linux-x86_64, etc.), not from per-repobuildenv.shBINARIESstrings. The drift surface this issue was tracking — wrong artifact suffix, mismatched binary list, deleted helper scripts — is largely abuildenv.shproblem, whichhero_builderremoves.What's left for this issue under D-07 + D-08:
buildenv.shand invokehero_builderdirectly in.forgejo/workflows/build-linux.yaml. Per-repo, opportunistic; folded into whatever PR next touches each workflow.Status carried into home#230 Phase 4 (CI fix-forwards — opportunistic, not gating per D-07).
Filed at session 80 close.