ci: add GitHub Action to build the kvm_x86_64 ONIE image

[bhouse-nexthop]

Summary

Adds a GitHub Actions workflow that builds the generic amd64 ONIE target (kvm_x86_64, intended to run as a VM under KVM/QEMU) on every push and pull request that touches the build.

The goal is to make reviewing other PRs easier: a green check confirms the change still produces a working ONIE image, so "it builds" becomes part of acceptance testing rather than something a reviewer has to verify by hand.

To keep that check fast enough to be practical on every PR, the workflow caches both the Docker build-environment image and the crosstool-NG cross toolchain. A cold build spends ~25 min compiling the toolchain alone; with the cache warm, subsequent PR runs restore it and skip straight to the ONIE build, so the per-PR runtime is dramatically shorter.

What it does

The build follows the upstream-recommended containerized flow (contrib/build-env and machine/kvm_x86_64/INSTALL) rather than any bespoke scripting:

• .github/onie-build/Dockerfile — a Debian 11 build environment. Debian 11 is required because build-config still pulls in python2-era tooling. The package set covers the legacy toolchain ONIE needs (autoconf/automake, bison/flex, gperf, stgit for the patch series, libefivar-dev for the UEFI path, xorriso, etc.); secure-boot/code-signing tooling is intentionally omitted. The build runs as a build user whose UID/GID match the host runner so artifacts are not left root-owned.
• Secure boot disabled — no signing keys to manage. The workflow swaps in the repo's shipped machine/kvm_x86_64/kernel/config-insecure and passes SECURE_BOOT_ENABLE=no SECURE_BOOT_EXT=no SECURE_GRUB=no, then runs the standard make MACHINE=kvm_x86_64 all recovery-iso.

Caching — keeping per-PR runtime low

These are the levers that make running on every PR practical:

• Docker build-env image — built with docker/build-push-action + GitHub Actions layer caching, so the apt install layer is reused across runs instead of rebuilt every time.
• Cross toolchain — the crosstool-NG toolchain (build/x-tools + build/crosstool-ng) is the long pole of a cold build (~25 min). It's built as a discrete xtools target and cached, so warm runs restore it and skip the compile entirely. The key hashes every toolchain input — xtools.make, crosstool-ng.make, compiler.make, conf/crosstool, the crosstool-NG patches, and the Dockerfile (it defines the environment the toolchain is built in). No loose restore-keys, so any input change forces a clean rebuild rather than restoring a mismatched toolchain. The cache is saved only after the toolchain build succeeds and before the full build, so a broken toolchain is never cached and a later-stage failure still preserves the toolchain.

Other hygiene

• apt retries — Acquire::Retries so transient Debian mirror resets don't fail the build.
• Concurrency group — workflow + ref with cancel-in-progress, so a newer push to the same branch cancels the prior run instead of stacking concurrent builds.

Testing

Validated end-to-end in this fork: the workflow builds the kvm_x86_64 image (kernel, initrd, onie-updater, recovery ISO) successfully.

[bhouse-nexthop]

Closing — opening this against the upstream parent (opencomputeproject/onie) instead of the fork.