菜单
Run Hypeman tests on a remote Linux host that supports the Linux hypervisors. Use when validating cloud-hypervisor, Firecracker, QEMU, embedded guest artifacts, or Linux-only integration behavior on a server over SSH.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Improve repository test quality by eliminating flakes first, then reducing slow-test redundancy, and finally optimizing longest tests while preserving coverage. Use when asked to repeatedly run CI-equivalent no-cache test cycles, diagnose flaky tests, and document findings in this skill's notes.
Use when optimizing VM Initializing-to-Running latency while preserving functionality and low implementation complexity.
Add or adjust monitoring for a Hypeman feature using repository standards for logs, traces, and metrics. Use when a user asks for instrumentation, observability reviews, telemetry consistency changes, metric design, or production-signal improvements.
| name | hypeman-remote-linux-tests |
| description | Run Hypeman tests on a remote Linux host that supports the Linux hypervisors. Use when validating cloud-hypervisor, Firecracker, QEMU, embedded guest artifacts, or Linux-only integration behavior on a server over SSH. |
Use this skill to run Hypeman tests on a remote Linux server in a way that is repeatable and low-friction for any developer.
/usr/sbin and /sbin on PATH.go test.Prefer a short path such as ~/hm, ~/hypeman-test, or another short directory name.
Cloud Hypervisor uses UNIX sockets with strict path-length limits. Long paths from default test temp directories or deeply nested clones can make the VMM fail before the actual test starts.
If a new test creates temporary directories for guest data, prefer a short root like:
mktemp -d /tmp/hmcmp-XXXXXX
Before running Linux hypervisor tests, make sure the remote clone has the generated guest binaries and embedded VMM assets:
export PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:$PATH
make ensure-ch-binaries ensure-firecracker-binaries ensure-caddy-binaries build-embedded
Why:
go:embed patterns in the repo require the bundled binaries to exist at build time.mkfs.ext4 is commonly installed in /usr/sbin or /sbin, not always on the default non-login shell PATH.go test before this bootstrap often fails during package setup, not during test execution.QEMU is usually provided by the host OS, so there is no matching bundled ensure-qemu-binaries target. If QEMU tests fail before boot, verify the system qemu-system-* binary separately.
If the main development is happening locally and the Linux host is only for execution, sync only the files you changed rather than recloning every time.
Typical pattern:
rsync -az lib/instances/... remote-host:~/hypeman-test/lib/instances/
After syncing, re-run the bootstrap command if the changes affect embedded binaries, generated assets, or files referenced by go:embed.
Classify failures quickly:
pattern ... no matching files foundmake ensure-ch-binaries ensure-firecracker-binaries ensure-caddy-binaries build-embeddedmkfs.ext4 not found:
exec: "mkfs.ext4": executable file not found/usr/sbin:/sbin to PATH, then retrypath must be shorter than SUN_LEN/tmp or shared test-lock issues: