[CI] development red — `cargo check` fails: planner_admin askama can't find hero_lib templates #23

New issue

Closed

opened 2026-06-14 16:05:10 +00:00 by sameh-farouk · 1 comment

sameh-farouk commented

2026-06-14 16:05:10 +00:00

Member

CI on development is red (main is green). Failing step: check (cargo check --workspace, .forgejo/workflows/lab-release.yaml).

Error:

Checking hero_planner_admin v0.1.0 (/workspace/lhumina_code/hero_planner/crates/hero_planner_admin)
error: template "parts/hero_head.html" not found in directories [".../hero_planner_admin/../../../hero_lib/crates/hero_lifecycle/src/webserver/templates", ...]
  --> crates/hero_planner_admin/templates/planner_admin_base.html:4:6
error: could not compile `hero_planner_admin` (bin "hero_planner_admin") due to 1 previous error

Root cause: the askama webserver-admin migration set hero_planner_admin/askama.toml dirs to relative filesystem paths into a hero_lib sibling checkout:

dirs = [
  "../../../hero_lib/crates/hero_lifecycle/src/webserver/templates",
  ... ,
  "templates",
]

In CI (and any normal build) hero_lib is a cargo git dependency (under $CARGO_HOME/git/...), NOT a sibling at ../../../hero_lib, so askama's compile-time template resolution fails. (Locally it only builds if you happen to have hero_lib checked out as a sibling — which is how it was being built by hand.)

Why main is green: main predates the migration — its hero_planner_admin is the old hand-rolled index.html + main.rs (no askama.toml, no relative-template dependency).

Scope / proper fix: this affects every service using the hero_lifecycle webserver-admin pattern in CI, so the fix likely belongs in hero_lifecycle — make the shared webserver templates resolvable from the git dependency (embed/package them, or resolve via the dep's real path) instead of a hardcoded relative sibling path. Related shared-admin issue: #151 (hero_lib).

CI on `development` is **red** (main is green). Failing step: **check** (`cargo check --workspace`, `.forgejo/workflows/lab-release.yaml`). **Error:** ``` Checking hero_planner_admin v0.1.0 (/workspace/lhumina_code/hero_planner/crates/hero_planner_admin) error: template "parts/hero_head.html" not found in directories [".../hero_planner_admin/../../../hero_lib/crates/hero_lifecycle/src/webserver/templates", ...] --> crates/hero_planner_admin/templates/planner_admin_base.html:4:6 error: could not compile `hero_planner_admin` (bin "hero_planner_admin") due to 1 previous error ``` **Root cause:** the askama webserver-admin migration set `hero_planner_admin/askama.toml` `dirs` to **relative filesystem paths into a `hero_lib` sibling checkout**: ``` dirs = [ "../../../hero_lib/crates/hero_lifecycle/src/webserver/templates", ... , "templates", ] ``` In CI (and any normal build) `hero_lib` is a **cargo git dependency** (under `$CARGO_HOME/git/...`), NOT a sibling at `../../../hero_lib`, so askama's compile-time template resolution fails. (Locally it only builds if you happen to have `hero_lib` checked out as a sibling — which is how it was being built by hand.) **Why main is green:** `main` predates the migration — its `hero_planner_admin` is the old hand-rolled `index.html` + `main.rs` (no `askama.toml`, no relative-template dependency). **Scope / proper fix:** this affects every service using the hero_lifecycle webserver-admin pattern in CI, so the fix likely belongs in **hero_lifecycle** — make the shared webserver templates resolvable from the git dependency (embed/package them, or resolve via the dep's real path) instead of a hardcoded relative sibling path. Related shared-admin issue: #151 (hero_lib).

sameh-farouk self-assigned this

2026-06-14 16:05:10 +00:00

sameh-farouk referenced this issue from a commit

2026-06-14 16:35:41 +00:00

fix(admin): vendor shared hero_lifecycle partials so CI cargo check passes (#23)

sameh-farouk commented

2026-06-14 18:01:23 +00:00

Author

Member

Fixed on development in 6499ae7 — vendored the 3 shared hero_lifecycle partials (hero_head, hero_connection_status, hero_scripts) into hero_planner_admin/templates/parts/ and set askama dirs=["templates"], so the crate compiles without a hero_lib sibling checkout (CI resolves hero_lib as a git dependency).

Verified two ways: (1) cargo check --workspace exits 0 with ~/hero/code/hero_lib moved aside (exact CI conditions); (2) CI run #62 on development = SUCCESS — the prior runs #58–61 all failed at this check step.

The proper shared fix (expose templates via cargo links/DEP_*) is tracked in hero_lib #152; the vendored copies are marked temporary (askama.toml TODO -> #152) and are obsoleted by the Dioxus admin (#18).

Fixed on `development` in `6499ae7` — vendored the 3 shared hero_lifecycle partials (`hero_head`, `hero_connection_status`, `hero_scripts`) into `hero_planner_admin/templates/parts/` and set askama `dirs=["templates"]`, so the crate compiles without a hero_lib *sibling checkout* (CI resolves hero_lib as a git dependency). **Verified two ways:** (1) `cargo check --workspace` exits 0 with `~/hero/code/hero_lib` moved aside (exact CI conditions); (2) **CI run #62 on `development` = SUCCESS** — the prior runs #58–61 all failed at this `check` step. The proper shared fix (expose templates via cargo `links`/`DEP_*`) is tracked in hero_lib #152; the vendored copies are marked temporary (askama.toml TODO -> #152) and are obsoleted by the Dioxus admin (#18).

sameh-farouk closed this issue

2026-06-14 18:01:23 +00:00