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 pull equivalent - apps are deployed from source

Building WendyOS (Yocto)

WendyOS images are built with Yocto. Three meta layers exist:

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 shell

See 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 test

Important: 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 .serialized trait on test suites to avoid VM race conditions
• •Set E2E_USE_EXISTING_VM=true to 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

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 issues
• •references/system-internals.md - containerd runtime, containerd-registry, device identity, mDNS configuration, Lima VM development, offline image bundling
• •references/raspberry-pi.md - RPi machine configuration, serial console, flashing images, partition layout