fix(deps): pin herolib_* to commit ab985c9 (unblock first release) #15

Merged
mik-tf merged 1 commit from development_mik_home212_lib_rhai_unblock into development 2026-05-06 18:05:17 +00:00
Owner

Refs lhumina_code/home#212

Follow-up to PR #14 — fixes the dep-resolution failure that blocked the v0.1.0-rc1 build (https://forge.ourworld.tf/lhumina_code/hero_lib_rhai/actions/runs/64).

Root cause

14 of the 15 herolib_* git deps in Cargo.toml referenced branch = "development_casper" on lhumina_code/hero_lib. That branch was merged into development and deleted upstream — only development and main exist on hero_lib today. Local builds still worked because workstation cargo caches held the deleted ref, but a fresh CI checkout failed at dep resolution:

failed to find branch `development_casper`
cannot locate remote-tracking branch 'origin/development_casper';
class=Reference (4); code=NotFound (-3)

This repo had never been CI-built before (zero published tags), which is why the rot went unnoticed.

Fix

Replace branch = "development_casper" with rev = "ab985c901e591e69c06fd0abd924a6159c8cc77d" for all 14 deps. That commit is the merge point of the deleted branch and is reachable from current origin/development (16 commits behind HEAD). Cargo.lock confirmed every herolib_* dep was pinned to this exact rev already, so this preserves bit-identical build inputs and pulls in zero upstream changes.

herolib_core was already on branch = "development" and is left untouched.

Why rev-pin instead of switching to branch = "development"

Cleaner long-term — fresh development would silently pull in the AI broker rewrite (refactor(ai): rewrite as broker-first architecture) and openrpc transport migration that landed after ab985c9. Either of those could break compilation against this workspace's bindings; that's an integration story for a separate session, not a CI-unblock.

After merge

Retag v0.1.0-rc2 from development HEAD; CI should publish 4 release assets matching the workflow shipped in #14:

hero_do-x86_64-unknown-linux-musl
hero_runner_rhai-x86_64-unknown-linux-musl
hero_runner_rhai_server-x86_64-unknown-linux-musl
hero_runner_rhai_ui-x86_64-unknown-linux-musl

Consumer-side flip in lhumina_code/hero_skills#221 lands once the assets exist.

Signed-off-by: mik-tf

Refs https://forge.ourworld.tf/lhumina_code/home/issues/212 Follow-up to PR #14 — fixes the dep-resolution failure that blocked the v0.1.0-rc1 build (https://forge.ourworld.tf/lhumina_code/hero_lib_rhai/actions/runs/64). ## Root cause 14 of the 15 `herolib_*` git deps in `Cargo.toml` referenced `branch = "development_casper"` on `lhumina_code/hero_lib`. That branch was merged into `development` and deleted upstream — only `development` and `main` exist on hero_lib today. Local builds still worked because workstation cargo caches held the deleted ref, but a fresh CI checkout failed at dep resolution: ``` failed to find branch `development_casper` cannot locate remote-tracking branch 'origin/development_casper'; class=Reference (4); code=NotFound (-3) ``` This repo had never been CI-built before (zero published tags), which is why the rot went unnoticed. ## Fix Replace `branch = "development_casper"` with `rev = "ab985c901e591e69c06fd0abd924a6159c8cc77d"` for all 14 deps. That commit is the merge point of the deleted branch and is reachable from current `origin/development` (16 commits behind HEAD). Cargo.lock confirmed every herolib_* dep was pinned to this exact rev already, so this preserves bit-identical build inputs and pulls in zero upstream changes. `herolib_core` was already on `branch = "development"` and is left untouched. ## Why rev-pin instead of switching to `branch = "development"` Cleaner long-term — fresh `development` would silently pull in the AI broker rewrite (`refactor(ai): rewrite as broker-first architecture`) and openrpc transport migration that landed after `ab985c9`. Either of those could break compilation against this workspace's bindings; that's an integration story for a separate session, not a CI-unblock. ## After merge Retag `v0.1.0-rc2` from `development` HEAD; CI should publish 4 release assets matching the workflow shipped in #14: ``` hero_do-x86_64-unknown-linux-musl hero_runner_rhai-x86_64-unknown-linux-musl hero_runner_rhai_server-x86_64-unknown-linux-musl hero_runner_rhai_ui-x86_64-unknown-linux-musl ``` Consumer-side flip in https://forge.ourworld.tf/lhumina_code/hero_skills/pulls/221 lands once the assets exist. Signed-off-by: mik-tf
fix(deps): pin herolib_* to commit ab985c9 (development_casper branch deleted upstream)
Some checks failed
Lint / lint-linux (pull_request) Failing after 4s
Tests / test-linux (pull_request) Failing after 23s
ec3e827ed3
Cargo.toml referenced `branch = "development_casper"` on 14 herolib_*
git deps. That branch no longer exists on
https://forge.ourworld.tf/lhumina_code/hero_lib — only `development`
and `main` are present today. Local cargo built fine because workstation
caches still hold the deleted ref, but a fresh CI checkout (i.e. the
v0.1.0-rc1 build) failed at dep resolution.

The branch had been merged into `development` and deleted; the merge
commit is ab985c901e591e69c06fd0abd924a6159c8cc77d, which is reachable
from current `origin/development` (16 commits behind HEAD). Pinning
each dep to that exact rev gives us:

- bit-identical build inputs to whatever was working pre-deletion;
- self-resolving Cargo.toml on fresh checkouts (no dependency on
  branch refs that may move or vanish);
- no upstream churn pulled in (the alternative — switch to
  `branch = "development"` — would silently follow new commits like
  the AI broker rewrite + openrpc transport migration).

herolib_core was already on `branch = "development"` and is left as-is.

This unblocks v0.1.0-rc2 — the first hero_lib_rhai release.

Refs lhumina_code/home#212

Signed-off-by: mik-tf
Author
Owner

Follow-up issue filed for the underlying API debt this PR works around:

The rev-pin shipped here is intentional and explicit — it gets lifted when #16 lands. We tested switching the 14 herolib_* deps to branch = "development": cargo check --workspace returned 39 errors in crates/ai_rhai/src/lib.rs driven by the broker-first herolib_ai rewrite. That's a separate (architectural) work item under home#219, not session 65 scope (home#212 binaries).

Follow-up issue filed for the underlying API debt this PR works around: - https://forge.ourworld.tf/lhumina_code/hero_lib_rhai/issues/16 — modernize ai_rhai for broker-first herolib_ai (child of https://forge.ourworld.tf/lhumina_code/home/issues/219) The rev-pin shipped here is intentional and explicit — it gets lifted when #16 lands. We tested switching the 14 `herolib_*` deps to `branch = "development"`: `cargo check --workspace` returned 39 errors in `crates/ai_rhai/src/lib.rs` driven by the broker-first `herolib_ai` rewrite. That's a separate (architectural) work item under home#219, not session 65 scope (home#212 binaries).
mik-tf merged commit 11651daacf into development 2026-05-06 18:05:17 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
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_lib_rhai!15
No description provided.