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
38 lines
2.0 KiB
Markdown
38 lines
2.0 KiB
Markdown
# 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:
|
|
|
|
1. **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.
|
|
2. **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's
|
|
`gcc-arm-linux-gnueabihf`, and self-provisions `python`. 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.
|