[ci] lab publish fails in the build stage for several repos after the install-path fix #240
Labels
No labels
meeting-notes
meeting-transcript
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/home#240
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?
After the release workflows were fixed to find lab at its new install location (~/.local/bin), the publish job now runs but fails during the actual build for some repos. A sample showed hero_memory, hero_rpc, and hero_skills running for a few minutes and then failing, so it is the workspace build itself, not the tooling, and their latest release no longer refreshes. We should audit every repo's publish run, list each one that fails to build, and fix the build errors per repo so latest refreshes everywhere.
Signed-by: mik-tf mik-tf@noreply.invalid
Update from the completed publish runs: hero_skills now publishes successfully (its earlier failure did not persist), and the gnu variant publish (the voice provider) is also green, so the path fix is confirmed for both the musl and gnu publish workflows. In this sample the runs that still fail in the build stage are hero_rpc and hero_memory. A full audit across every component is still needed to list all remaining build failures, but the workflow fix itself is confirmed working.
Signed-by: mik-tf mik-tf@noreply.invalid
Audited every repo's latest publish run and fixed the build-stage failures. Two distinct root causes showed up. First, some repos still pinned package names and an ONNX/gnu build path that the recent crate-layout rewrites removed: hero_memory now builds the whole workspace on musl with the obsolete gnu+ONNX workflow deleted, hero_voice dropped the removed hero_voiced package, and hero_agent was rerouted off the retired hero_embedder library onto hero_memory for its semantic tool routing and knowledge-base search. Second, hero_collab and hero_wallet gitignored their Cargo.lock, so CI resolved git dependencies fresh on every run and broke whenever an upstream branch head moved (here, a shared core crate that predated a build-banner constant); both now commit the lock like the other binary-shipping repos. All five publish green or are publishing. hero_skills and hero_voice_provider were already green.
Two are intentionally left for follow-up. hero_lib_rhai's gnu build needed an os-bindings feature fix (done) but then hits a cross-repo version skew between hero_db and hero_rpc (a missing hero_rpc2 export) that needs a coordinated, committed lock across those repos. hero_blueprint's publish fails on a newly added crm example that is not excluded from the workspace build; the shipped library crates compile fine and consumers pull them as source, so this does not block anything downstream, and the example is owned by its author. Separately, hero_os still references the retired embedder behind an optional feature, but it has no publish workflow so nothing breaks today.
Another instance of the publish-without-rebuild failure, this time on hero_proc. The latest release was carrying a hero_proc_server (and hero_proc_admin) binary whose embedded service manifest still used the old socket field name, so the current shared-library schema rejected it and the binary panicked on startup. On a freshly provisioned tester the process supervisor could not start at all, so nothing else in the stack came up either. The publish workflow had reported success while its sibling build step failed, which is how the stale binary shipped with a fresh-looking timestamp. I rebuilt both binaries from the current development source, confirmed they validate and start, and replaced the linux-musl-x86_64 server and admin assets on the latest release, so a fresh download now starts cleanly. The structural fix is to make the publish step fail when its build step fails, so a stale artifact can never be re-uploaded as a success.
Signed-by: mik-tf mik-tf@noreply.invalid