feat: fresh Ubuntu testing#2312
Conversation
Greptile SummaryAdds a local VirtualBox-based test harness (
Confidence Score: 4/5Safe to merge as a local tooling addition; no production code is affected, but vmtest.sh has a logic flaw in ISO handling that will cause confusing build failures for anyone whose download was interrupted. The misc/fresh-ubuntu-tests/vmtest.sh — specifically the Important Files Changed
Sequence DiagramsequenceDiagram
participant User
participant vmtest.sh
participant VBoxManage
participant GoldenVM
participant CloneVM
participant suite/run.sh
Note over User,suite/run.sh: ./vmtest.sh build (once)
User->>vmtest.sh: build
vmtest.sh->>vmtest.sh: ensure_iso() — wget ISO
vmtest.sh->>VBoxManage: createvm + unattended install
VBoxManage->>GoldenVM: start headless, install Ubuntu
GoldenVM-->>vmtest.sh: SSH ready (/etc/dimos-vmtest-ready)
vmtest.sh->>VBoxManage: power off + snapshot "golden"
Note over User,suite/run.sh: ./vmtest.sh run (each time)
User->>vmtest.sh: run
vmtest.sh->>VBoxManage: clonevm golden --options link → CloneVM
VBoxManage->>CloneVM: startvm headless
CloneVM-->>vmtest.sh: SSH ready
vmtest.sh->>CloneVM: scp suite/
vmtest.sh->>CloneVM: ssh bash suite/run.sh
CloneVM->>suite/run.sh: setup.sh (apt-get, uv, git clone)
suite/run.sh->>suite/run.sh: 01-mypy.sh
suite/run.sh->>suite/run.sh: 02-pytest.sh
suite/run.sh->>suite/run.sh: 03-cyclonedds.sh
suite/run.sh-->>vmtest.sh: PASS / FAIL + exit code
vmtest.sh->>CloneVM: scp logs back
vmtest.sh->>VBoxManage: remove CloneVM (trap EXIT)
Reviews (1): Last reviewed commit: "feat: fresh ubuntu testing" | Re-trigger Greptile |
| if [[ -f "$ISO_PATH" ]]; then | ||
| return | ||
| fi | ||
|
|
||
| wget --tries=3 --continue -O "$ISO_PATH" "https://releases.ubuntu.com/$RELEASE/$fname" \ | ||
| || die "download failed" |
There was a problem hiding this comment.
Partial download silently accepted as a valid ISO. The
if [[ -f "$ISO_PATH" ]]; then return; fi guard fires as soon as the file exists — even if a previous wget was interrupted mid-download. The --continue flag on the wget call below is unreachable in this case, so the partial file is passed to VirtualBox as-is. The unattended install will then fail with a cryptic installer error rather than a clear "ISO is corrupt" message. The fix is to skip the early return and let wget --continue resume (or verify the file is complete after creation).
| if [[ -f "$ISO_PATH" ]]; then | |
| return | |
| fi | |
| wget --tries=3 --continue -O "$ISO_PATH" "https://releases.ubuntu.com/$RELEASE/$fname" \ | |
| || die "download failed" | |
| wget --tries=3 --continue -O "$ISO_PATH" "https://releases.ubuntu.com/$RELEASE/$fname" \ | |
| || die "download failed" |
| readonly RELEASE="24.04" | ||
| readonly VM="dimos-vmtest-base" |
There was a problem hiding this comment.
The minor point-release version (
4) in the ISO filename is hardcoded separately from the RELEASE constant. When Ubuntu publishes 24.04.5, this script will silently keep downloading the older .4 image (or get a 404 if Canonical eventually removes it). Deriving the full filename from a single versioned constant keeps them in sync and makes future bumps a one-liner.
| readonly RELEASE="24.04" | |
| readonly VM="dimos-vmtest-base" | |
| readonly RELEASE="24.04" | |
| readonly RELEASE_POINT="24.04.4" # bump when Ubuntu publishes a new point release | |
| readonly VM="dimos-vmtest-base" |
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| ensure_iso() { | ||
| need wget | ||
| mkdir -p "$ISO_DIR" | ||
| local fname="ubuntu-24.04.4-desktop-amd64.iso" | ||
| ISO_PATH="$ISO_DIR/$fname" | ||
|
|
||
| if [[ -f "$ISO_PATH" ]]; then | ||
| return | ||
| fi | ||
|
|
||
| wget --tries=3 --continue -O "$ISO_PATH" "https://releases.ubuntu.com/$RELEASE/$fname" \ | ||
| || die "download failed" | ||
| } |
There was a problem hiding this comment.
No SHA-256 integrity check after download. Ubuntu publishes
SHA256SUMS and SHA256SUMS.gpg alongside every ISO at https://releases.ubuntu.com/24.04/. Without verifying the checksum, a corrupted download (e.g., from a flaky connection, CDN error, or partial wget resume misalignment) passes silently into VirtualBox. Adding a sha256sum -c step after wget completes — using the checksum fetched from Ubuntu — would catch bad downloads before the ~15-30 min install begins.
| readonly MEM=12288 # MiB | ||
| readonly CPUS=8 | ||
| readonly DISK=40960 # MiB (dynamic; only grows as used) | ||
| readonly SSH_PORT=2222 |
There was a problem hiding this comment.
Hardcoded
SSH_PORT shared between golden VM and all clones. The golden VM's NAT rule binds 127.0.0.1:2222 → :22 at build time. Every linked clone inherits the same rule. If the golden VM is still running (e.g., left up after a previous build) when run starts its clone, both VMs compete for port 2222; VirtualBox doesn't error out but the SSH connection may reach the wrong VM or fail intermittently. A simple guard (vm_state "$VM" != "running") at the start of cmd_run — or stopping the golden VM if it is running — would prevent this.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
Problem
Closes DIM-968
Solution
How to Test
Contributor License Agreement