From 683a7f31e64892e5c13e027899d7182e8d53e693 Mon Sep 17 00:00:00 2001 From: David Montero Date: Mon, 18 May 2026 15:56:54 +0200 Subject: [PATCH] test(coverage): accept raspberry-pi-4 and raspberry-pi-5 as uncovered MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Pi 4 and Pi 5 were added to the BoardKind union in db5e3a8 ("feat(pi3 phase 3.1+3.2): Pi 3/4/5 family via PI_CONFIGS") but no gallery example ships for them — same situation as Pi 3, which is already accepted. All three boot a full Linux image under QEMU on the backend; there is no in-browser canvas demo to register. --- frontend/src/__tests__/board-kinds-coverage.test.ts | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/frontend/src/__tests__/board-kinds-coverage.test.ts b/frontend/src/__tests__/board-kinds-coverage.test.ts index 3c177713..69b02fb7 100644 --- a/frontend/src/__tests__/board-kinds-coverage.test.ts +++ b/frontend/src/__tests__/board-kinds-coverage.test.ts @@ -41,9 +41,11 @@ const ALL_EXAMPLES: ExampleProject[] = [ * coverage gap visible at code-review time. */ const ACCEPTED_UNCOVERED: ReadonlySet = new Set([ - // Pi 3B runs on the backend (QEMU ARM64) — no in-browser canvas - // example because it boots a full Linux image. + // Pi 3/4/5 run on the backend (QEMU ARM64) — no in-browser canvas + // example because they boot a full Linux image. 'raspberry-pi-3', + 'raspberry-pi-4', + 'raspberry-pi-5', // ESP32 Xtensa LX6 variants — all share the same QEMU backend as // the primary `esp32` boardKind (which IS covered). Adding a