Append a v0.5.32 entry documenting that ISO builds moved from GitHub Actions to the Forgejo runner on nullstone, that the hybrid VM test procedure is unchanged, that the ISO is now pulled from the ci-latest Forgejo release tag, and that virtio-9p host log capture is on by default (replaces the broken virtio-serial path flagged by Agent 6 in the 2026-05-05 wave). TESTING.md itself is intentionally untouched — only the build host and download URL changed; the procedure prose still applies as-is.
85 lines
3.8 KiB
Markdown
85 lines
3.8 KiB
Markdown
# veilor-os — Test Method Changelog
|
|
|
|
Append-only log of changes to `test/TESTING.md`. Each entry: date, the
|
|
veilor-os version it first applied to, what changed in the procedure,
|
|
and *why*. The why is the load-bearing part — without it this file
|
|
becomes a list of opinions.
|
|
|
|
Entries are newest-first.
|
|
|
|
---
|
|
|
|
## 2026-05-06 · v0.5.32 · ISO build path moved to Forgejo
|
|
|
|
**Change:** Build host for the test ISO has moved off GitHub Actions
|
|
onto the Forgejo runner on nullstone. The hybrid VM test procedure in
|
|
`TESTING.md` is **unchanged** — the gum installer still drives every
|
|
step it can, the operator still types the LUKS + admin passwords
|
|
directly into the QEMU window. The only thing different is where the
|
|
ISO comes from and how the host log is captured.
|
|
|
|
**Practical deltas for testers:**
|
|
|
|
- ISO download: from the Forgejo `ci-latest` rolling release at
|
|
<https://git.s8n.ru/veilor-org/veilor-os/releases/tag/ci-latest>.
|
|
The tag is force-replaced on each successful `build-iso.yml` run, so
|
|
always re-download — don't rely on a cached copy.
|
|
- Re-flash to USB / virtio-blk image via Etcher / `dd` — **unchanged**.
|
|
Same `sha256sum -c` step; same image format.
|
|
- virtio-9p host log capture is now **active by default** in
|
|
`test/run-vm.sh`. This replaces the broken virtio-serial path
|
|
flagged by Agent 6 in the 2026-05-05 wave; Anaconda logs land in the
|
|
host-side mount automatically once the VM boots, no manual `tail -f`
|
|
on a broken serial console.
|
|
- Build host for the record: forgejo-runner on nullstone, runner label
|
|
`ubuntu-24.04`, image `catthehacker/ubuntu:act-24.04`. Reproducibility
|
|
is unchanged from the GH Actions ubuntu-24.04 base — the act image
|
|
matches GHA's runner image to within package versions.
|
|
|
|
**Why:** GitHub mirror was disabled 2026-05-06 (repo is now
|
|
private-by-default on Forgejo); GH Actions builds would just stop
|
|
producing artifacts. Moving CI in-house onto nullstone keeps the
|
|
test/release loop intact and removes the external dependency for
|
|
private-build cycles. Documenting the change here so a future tester
|
|
reading TESTING.md doesn't waste time hunting an artifact in a
|
|
GitHub run that never happened.
|
|
|
|
**Files touched in this entry:**
|
|
- `test/METHOD-CHANGELOG.md` — this entry.
|
|
|
|
`test/TESTING.md` itself is **not** edited — the procedure prose still
|
|
applies verbatim. Only the build host and the URL where the ISO lives
|
|
changed.
|
|
|
|
---
|
|
|
|
## 2026-05-05 · v0.5.27 · TESTING.md created
|
|
|
|
**Change:** First version of the canonical procedure document.
|
|
|
|
**Why:** Through v0.2 → v0.5.26 we'd been reproducing the test
|
|
procedure ad-hoc each time, which meant test runs were uncomparable
|
|
and regressions were caught only by accident. The v0.5.26 → v0.5.27
|
|
debugging session surfaced the LUKS-cmdline bug, the GRUB rebrand
|
|
gap, the gum-cursor render glitch, and the fbcon KMS issue all in a
|
|
single VM run — but only because the test happened to walk every step
|
|
in order. Codifying the steps means the next regression is caught the
|
|
same way reliably.
|
|
|
|
The procedure documents the **hybrid VM method** explicitly: Claude
|
|
drives every step it can via QEMU monitor `sendkey`, the human types
|
|
LUKS + admin passwords directly into the QEMU window because plymouth
|
|
ignores synthesised keystrokes. Past trail (14+ failed sendkey
|
|
variants) is the source of truth for that limitation; do not re-fight
|
|
that battle without first rereading the trail.
|
|
|
|
The procedure also separates **VM** (cheap iteration, catches install
|
|
logic) from **real hardware** (mandatory for tag, catches firmware /
|
|
KMS / GPU). Future releases must produce a `test/test-runs/` report
|
|
for each before tagging.
|
|
|
|
**Files added:**
|
|
- `test/TESTING.md` — canonical procedure
|
|
- `test/METHOD-CHANGELOG.md` — this file
|
|
- `test/test-runs/` — per-run reports go here (template lands with
|
|
first real run, currently empty)
|