-
Notifications
You must be signed in to change notification settings - Fork 1
Open
Labels
Description
Context
We now have container-based testing for Linux distros (Ubuntu, Arch, Chimera) via test/containers/. This issue tracks research into testing options for the remaining platforms where containers aren't a viable option.
macOS
- UTM / Parallels — Full macOS VMs, manual setup
- Tart — macOS-native VM tool using Apple Virtualization framework, designed for CI use
- Anka — Commercial macOS VM solution (Veertu), popular in CI/CD pipelines
- GitHub Actions —
macos-latestrunners available, but limited to what GHA provides (no persistent state)
No container option exists for macOS.
Windows
- Windows Sandbox — Lightweight, disposable, WIP-level support for automation
- Windows containers — Limited to Server Core / Nano Server images, not full desktop Windows
- Vagrant + VirtualBox/Hyper-V — Full VM, heavier but more realistic
- GitHub Actions —
windows-latestrunners available
FreeBSD
- Vagrant boxes — Official FreeBSD boxes exist and are well-maintained
- bhyve / QEMU — Native FreeBSD hypervisor or QEMU for local VMs
- Cirrus CI — Supports FreeBSD natively (GitHub Actions does not)
- FreeBSD Docker images — Community-maintained and limited; not a realistic test environment
- Firecracker / cloud-hypervisor — Linux-only microVMs, won't help for FreeBSD
Questions to Answer
- Which platforms are worth automating tests for vs. manual-only?
- What's the minimum viable test: just
script/bootstrap+chezmoi init, or fullsetup-full? - Should we use CI (GHA, Cirrus) or local VMs or both?
- Cost/complexity trade-offs for each approach
Related Issues
- Investigate VM-based testing tooling for dotfiles validation #58 — VM-based testing tooling investigation
- Test os-install scripts (Arch, Chimera) via VM-based automation #59 — OS installation script testing (Arch, Chimera)
Reactions are currently unavailable