WendyOS Contributing
This skill covers internal development and contribution to WendyOS itself, including building OS images, understanding agent architecture, and running E2E tests.
Overview
WendyOS is an Embedded Linux operating system for edge computing built with Yocto. It supports:
- NVIDIA Jetson devices (production with OTA updates)
- Raspberry Pi 4/5 (edge devices)
- ARM64 VMs (development)
Agent Architecture
The wendy-agent is a container daemon (similar to dockerd/containerd):
- Manages container lifecycle via gRPC on port 50051
- Images are pushed via
wendy run, not pulled from Docker Hub - There's no
docker pullequivalent - apps are deployed from source
Building WendyOS (Yocto)
WendyOS images are built with Yocto. Three meta layers exist:
| Layer | Target | Image |
|---|---|---|
meta-wendyos-jetson | NVIDIA Jetson | edgeos-image |
meta-wendyos-virtual | ARM64 VM | edgeos-vm-image |
meta-wendyos-rpi | Raspberry Pi 4/5 | edgeos-rpi-image |
Quick build (any layer):
cd meta-wendyos-<target>
./bootstrap.sh
source ./repos/poky/oe-init-build-env build
bitbake <image-name>For macOS, use the Docker build environment:
cd docker && ./docker-util.sh shellSee references/yocto-meta-layers.md for detailed Yocto configuration.
E2E Testing
The wendy-agent repository includes an E2E test suite in E2ETests/.
Running E2E Tests
# Start the VM
cd meta-wendyos-virtual
./scripts/setup-dev-vm.sh create && ./scripts/setup-dev-vm.sh start
# Deploy a test app first (required for container tests)
cd wendy-agent/Examples/HelloWorld
wendy run --json --device localhost:50051 # --json for non-interactive output
# Run E2E tests with fast path (CRITICAL for performance)
cd wendy-agent/E2ETests
E2E_USE_EXISTING_VM=true E2E_VM_PATH=/path/to/meta-wendyos-virtual swift testImportant: Always set E2E_USE_EXISTING_VM=true when the VM is already running. This skips shell script checks and reduces test time from ~5s/test to ~0.01s/test.
Tip: Use --json flag on all wendy commands for quick JSON responses without interactive polling.
Test Performance Tips
- Use
.serializedtrait on test suites to avoid VM race conditions - Set
E2E_USE_EXISTING_VM=trueto skip redundant VM status checks - mDNS discovery tests take ~5s each (inherent to protocol)
- Container state change tests can be slow - disable for quick runs
- Don't use
Issue.record()for expected failures (like WiFi in VM) - it counts as failure
CI Limitations
GitHub-hosted runners don't support nested virtualization. Use self-hosted runners or run E2E tests locally.
Test Suites
| Suite | Tests | Time | Notes |
|---|---|---|---|
| Device Connection | 7 | ~0.07s | gRPC connectivity |
| Container Deployment | 6 | ~0.06s | Container lifecycle |
| WiFi Operations | 4 | ~0.04s | Graceful failures in VM |
| Hardware Capabilities | 4 | ~0.07s | Device enumeration |
| Device Discovery | 4 | ~21s | mDNS (slow by design) |
System Internals
For debugging, container runtime details (containerd/nerdctl), mDNS discovery, device identity, and common pitfalls, see references/system-internals.md.
For Raspberry Pi specific configuration (serial console, flashing, partition layout), see references/raspberry-pi.md.
Reference Files
Load these files as needed for specific topics:
references/yocto-meta-layers.md- Yocto layer structure, build configuration, partition layouts, Docker build environment, common issuesreferences/system-internals.md- containerd runtime, containerd-registry, device identity, mDNS configuration, Lima VM development, offline image bundlingreferences/raspberry-pi.md- RPi machine configuration, serial console, flashing images, partition layout