BFE Engineering
c756622c96
The repo's documentation framed it as a support repo for one product (WardenOS). Since going public the real audience is anyone with a Luckfox Pico 86 Panel: a maintained 6.18 kernel, an off-device development loop, and a device simulator that exist nowhere else for this board. Reframe the README and top-level docs board-first, with WardenOS documented as the downstream consumer it is (ADR-0008). Also an editorial pass over the whole doc set: - every H1/H2 is now a short title, not a sentence (ADRs, qemu/, patches/, drivers/, architecture, NPU feasibility, config-lint, payload); workflow flowchart titles fixed at the source in tools/flowgen.py and regenerated with fresh bench numbers - README Quick Start commands verified against the scripts; requirements corrected (curl, bare python, gcc >= 14) and the MC/DC gate added as a step (run green locally on gcc 14.2) - dropped the 'needs python (not python3)' vendor dig: build-kernel.sh inherited the same requirement (filed #10 to remove it) - glossed MC/DC and HPMCU on first use; marked the tests/uboot-ab reference as flare-edge; deduplicated the three-simulator list into the root README table
2.0 KiB
2.0 KiB
ADR 0007 — Hosted-Only CI
Status: Accepted (2026-08-30). Supersedes the runner half of ADR-0004.
Context
The repo is going public (free Actions minutes for hosted runners; open-source alignment with the stack philosophy). Two facts change the ADR-0004 calculus:
- A self-hosted runner on a public repo is a standing hazard. A fork PR can modify workflow files; once any run of theirs is approved, workflows can target the repo's registered self-hosted runners — i.e. arbitrary code on the private host, which also serves production. GitHub's own guidance is to never attach self-hosted runners to public repos, and personal-account repos have no runner groups to scope the risk away.
- The build never needed the SDK host. ADR-0004's premise ("needs the SDK
toolchain and Buildroot's baked-in absolute paths") does not apply to
kernel-build: the hermetic build is freestanding, uses Debian'sgcc-arm-linux-gnueabihf, and self-provisionspython. It fits a hosted runner (4 vCPU / 16 GB), and public-repo minutes are free.
Decision
kernel-build runs on ubuntu-latest, apt-installing its toolchain, kernel
build deps, and qemu-system-arm, with the pristine tarball cached like
patches-apply does. It stays workflow_dispatch-only for now (a full build
per push is still noisy; flipping it to push-on-main later is one line). The
warden-sdk self-hosted runner instance is deregistered from this repo
before it goes public; the flare and flare-edge runner instances on the same
host are unaffected (those repos stay private).
Consequences
- No path from public workflows to private infrastructure; nothing to babysit in fork-PR approval settings beyond GitHub's defaults (still set "require approval for all outside contributors" as belt-and-braces).
- Kernel artifacts no longer persist on the runner host; the GitHub artifact (5-day retention + prune job) is the only build output channel.
- Hosted kernel builds are slower than the 0640 box but free and parallel; the boot-smoke step rides along unchanged.