lab build --download --install reports PASS for hero_cockpit + hero_os_tfgrid_deployer but binaries do not land in ~/hero/bin/ #303

New issue

Open

opened 2026-05-25 16:17:49 +00:00 by mik-tf · 1 comment

mik-tf commented

2026-05-25 16:17:49 +00:00

Owner

During s158 admin VM bootstrap via setup-binaries.sh, lab build hero_cockpit --download --install and lab build hero_os_tfgrid_deployer --download --install both reported PASS at the loop level but no hero_cockpit* or hero_tfgrid_deployer* binaries appeared in /home/driver/hero/bin/. The lab log showed:

=== hero_cockpit ===
→ hero_cockpit not found locally, searching Forge…
→ cloning lhumina_code/hero_cockpit into /home/driver/hero/code/hero_cockpit
→ building in /home/driver/hero/code/hero_cockpit
→ downloading from https://forge.ourworld.tf/lhumina_code/hero_cockpit/releases/tag/latest
repo:        /data/home/driver/hero/code/hero_cockpit
      PASS: hero_cockpit

But ls /home/driver/hero/bin/ | grep cockpit returned empty. The clone + build path appeared to silently fall through to download without actually installing.

This is similar in shape to issue patterns at hero_skills (lab orchestration) — the download phase might be reporting PASS without actually placing the binaries when the artifact name format doesn't match what lab expects, OR when the source build fails midway.

Workaround at s158: scp pre-built binaries from workstation ~/hero/bin/. Sustainable demo setup needs lab build --download --install to either succeed deterministically OR fail loudly so the operator knows to use a fallback path.

Affects every Hero OS bootstrap on a fresh TFGrid VM — without this fix, every admin VM provisioned by deployer.provision_vm will be missing the cockpit + deployer binaries that users actually interact with.

During s158 admin VM bootstrap via setup-binaries.sh, `lab build hero_cockpit --download --install` and `lab build hero_os_tfgrid_deployer --download --install` both reported PASS at the loop level but no `hero_cockpit*` or `hero_tfgrid_deployer*` binaries appeared in `/home/driver/hero/bin/`. The lab log showed: ``` === hero_cockpit === → hero_cockpit not found locally, searching Forge… → cloning lhumina_code/hero_cockpit into /home/driver/hero/code/hero_cockpit → building in /home/driver/hero/code/hero_cockpit → downloading from https://forge.ourworld.tf/lhumina_code/hero_cockpit/releases/tag/latest repo: /data/home/driver/hero/code/hero_cockpit PASS: hero_cockpit ``` But `ls /home/driver/hero/bin/ | grep cockpit` returned empty. The clone + build path appeared to silently fall through to download without actually installing. This is similar in shape to issue patterns at hero_skills (lab orchestration) — the download phase might be reporting PASS without actually placing the binaries when the artifact name format doesn't match what lab expects, OR when the source build fails midway. Workaround at s158: scp pre-built binaries from workstation `~/hero/bin/`. Sustainable demo setup needs `lab build --download --install` to either succeed deterministically OR fail loudly so the operator knows to use a fallback path. Affects every Hero OS bootstrap on a fresh TFGrid VM — without this fix, every admin VM provisioned by `deployer.provision_vm` will be missing the cockpit + deployer binaries that users actually interact with.

mik-tf referenced this issue from lhumina_code/home

2026-05-25 16:33:41 +00:00

[META] Hero OS demo-deployer arc tracker (cockpit + proxy + content + deployer + manifest + integration) #235

mik-tf commented

2026-05-26 02:38:11 +00:00

Author

Owner

Still relevant at s159. lab build --download --install continues to report PASS even when the install step does not actually deposit a binary in ~/hero/bin/. The s158 admin VM walk hit this for hero_cockpit (the manifest reported PASS but the binary had to be scp'd from the workstation as a workaround); see memory/reference_admin_vm_topology.md for the catalogued s158 workarounds. s159 did not touch this; left for Mahmoud or a dedicated lab-cli session.

Still relevant at s159. `lab build --download --install` continues to report PASS even when the install step does not actually deposit a binary in `~/hero/bin/`. The s158 admin VM walk hit this for `hero_cockpit` (the manifest reported PASS but the binary had to be `scp`'d from the workstation as a workaround); see `memory/reference_admin_vm_topology.md` for the catalogued s158 workarounds. s159 did not touch this; left for Mahmoud or a dedicated lab-cli session.