| name | lab-testing |
| version | 1.1 |
| last_updated | 2026-07-29 |
| id | lab-testing |
| one_line_purpose | Boot images on the KubeVirt lab and collect test logs. |
| entry_point | docs/skills/lab-testing/SKILL.md |
| category | test-authoring |
| mcp_compliance_level | partial |
| optimization_status | draft |
| status | active |
| dependencies | [] |
| tags | ["lab","testing","kubevirt"] |
| description | KubeVirt lab testing for common. Use when testing a common PR against bluefin, bluefin-lts, or dakota on ghost. |
| metadata | {"type":"reference"} |
Lab Testing — common layer on KubeVirt
projectbluefin/common is the shared OCI layer consumed by every downstream variant.
A regression in system_files/shared/ breaks bluefin, bluefin-lts, AND dakota simultaneously.
Lab testing on ghost catches what GitHub Actions E2E cannot: KVM-backed full boots,
real systemd unit activation, services that need device nodes, and cold-start timing.
When to use lab testing vs. GitHub Actions E2E
| Signal you want | Use |
|---|
| Pre-merge: does this common change compose correctly? | pr-e2e.yml (PR gate) |
| Post-merge: does the shared layer regress any variant? | e2e.yml (post-merge E2E) |
| Real systemd journal — any service failures? | Lab: log-scan-* workflows |
| Boot time, startup ordering, GNOME session smoke | Lab: bluefin-qa-pipeline suites=smoke |
| System contract (bootc, read-only /usr, staged deploy) | Lab: bluefin-qa-pipeline suites=system |
| Hardware-only bugs (suspend, USB-C, GPU PM) | Physical machines (exo-1 etc.) |
GitHub Actions E2E (e2e.yml) uses QEMU on ubuntu-latest runners.
The lab uses KubeVirt on ghost (Ryzen AI MAX+ 395, 64GB RAM, full KVM).
Neither replaces the other. Lab tests run on demand; E2E runs on every push.
Scope by changed path
| Changed path | Lab variants to test |
|---|
system_files/shared/** | bluefin + lts + dakota (all three) |
system_files/bluefin/** | bluefin + lts |
| dconf / GNOME settings | bluefin + lts (dakota GNOME stack is BST-sourced) |
just/, Justfile, *.just | all three (ujust ships to all variants) |
Containerfile changes | all three |
Posting lab results
When you verify a PR through the ghost cluster, the result must be posted as a
PR comment. This is the canonical evidence format
for cluster verification. Copy the template from
,
fill every field with real CLI evidence (workflow name/phase, , pod/VMI
state), and update an existing report comment from you rather than stacking duplicates.