End-to-end install verification of Windows MSI on a real Win10 host #21
Reference in New Issue
Block a user
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?
Follow-up to #18 (windows MSI sync) and the v1.1.0 release.
The cross-build path from issue #18 produced a functional MSI (verified statically via
msiinfo— 17 expected files bundled, ProductVersion=1.1.0, file table intact). End-to-end install verification on a real Windows host was deferred at v1.1.0 because the home fleet's general-purpose Win10 VM (VM113win10home) has no remote-exec channel:ping/sync/time/freeze/shutdown/get-vcpus/set-user-password— noguest-exec, noguest-file-write)Goal
A repeatable headless install-test loop: push MSI → install silently → start lmcp → curl the MCP endpoint → uninstall → repeat for every future release.
Two options
Bake OpenSSH-server into the existing test VM (or a fresh clone of VM106 dedicated to MSI testing, e.g.
lmcp-winbuild):scp + ssh msiexec /i ... /quietUpgrade qemu-guest-agent to a current version with full exec/file-write support:
qm guest execbecomes the headless channelOption 1 is more flexible (we can also
scparbitrary files and run interactive smoke tests). Option 2 is closer to "no extra services on Windows."Verification recipe (once a channel exists)
Priority
Low — the MSI structurally verified by
msiinfo, source code is byte-identical to the verified Linux build. Failure modes specific to Windows install (e.g. service registration, file ACLs, lua.exe missing a runtime DLL) are not covered by static checks. Worth fixing before the v2.0 release; not urgent before then.Done at v1.1.0 — not blocking this issue
wixl + mingw-w64reproducible viawindows/build-msi.shhertz:/opt/herding/artifacts/lmcp-1.1.0.msi