Skip to content

fix(ci): annotate per-board snippets with Pi Imager devices tags#2923

Open
vpetersson wants to merge 2 commits into
masterfrom
fix/ci-emit-devices-annotation
Open

fix(ci): annotate per-board snippets with Pi Imager devices tags#2923
vpetersson wants to merge 2 commits into
masterfrom
fix/ci-emit-devices-annotation

Conversation

@vpetersson
Copy link
Copy Markdown
Contributor

Issues Fixed

Pi Imager filters the OS list against the user-selected device. The Pi 5 entry in the upstream root JSON uses matching_type: exclusive — an image lacking a devices array is silently hidden when a user picks Pi 5 in the device picker. Raspberry Pi has signalled (Tom Dewey email, Nov 2023) that the same exclusive filter will roll out to older boards.

Our per-board JSON snippets currently emit no devices field, so even after we switch the upstream Anthias entry to subitems_url: https://anthias.screenly.io/rpi-imager.json, our Pi 5 build wouldn't surface to users.

Description

  • Map BOARD slug → device tags in the workflow's package step:
    • pi2["pi2-32bit"]
    • pi3["pi3-64bit"]
    • pi4-64["pi4-64bit"]
    • pi5["pi5-64bit"]
    • x86[] (not a Pi Imager target — empty array keeps the snippet schema-valid)
  • Add devices to REQUIRED_FIELDS in build_pi_imager_json.py so the contract is documented and the existing required-fields test enforces it.
  • Extend the test fixture's make_image_metadata to include devices, and add a per-board parametrized test that the field round-trips through retrieve_and_patch_json unmodified.

Tags taken from the canonical imager.devices[*].tags in https://downloads.raspberrypi.org/os_list_imagingutility_v4.json.

Checklist

  • I have performed a self-review of my own code.
  • New and existing unit tests pass locally and on CI with my changes.
  • I have done an end-to-end test for Raspberry Pi devices.
  • I have tested my changes for x86 devices.
  • I added a documentation for the changes I have made (when necessary).

Pi Imager filters the OS list against the user-selected device. The
Pi 5 entry in the upstream root JSON uses `matching_type: exclusive`,
so an image lacking a `devices` array is silently hidden when a user
picks Pi 5 in the device picker. Raspberry Pi has signalled (Nov 2023
Tom Dewey email) that the same exclusive filter will roll out to
older boards. Our per-board JSON snippets currently emit no `devices`
field — meaning fresh Anthias builds wouldn't surface in Pi Imager on
Pi 5 even if the upstream master list pointed at our subitems_url.

- Map BOARD slug → device tags in the workflow's package step
  (pi2 → pi2-32bit, pi3 → pi3-64bit, pi4-64 → pi4-64bit,
  pi5 → pi5-64bit, x86 → []).
- Extend REQUIRED_FIELDS in build_pi_imager_json.py so the contract
  is documented and the existing required-fields test enforces it.
- Update test fixtures + add a per-board devices-preservation test.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@vpetersson vpetersson requested a review from a team as a code owner May 19, 2026 18:14
@vpetersson vpetersson self-assigned this May 19, 2026
The Anthias pi3 image is 32-bit armhf (target_platform
`linux/arm/v7` in tools/image_builder/utils.py, with libraspberrypi0
linked via the Raspbian legacy userland — see image_builder/__main__.py
which calls out pi2/pi3 as the 32-bit boards). The balena image type
is `raspberrypi3` (32-bit), not `raspberrypi3-64`. Tagging this image
as `pi3-64bit` misdescribes what's in the .img.zst and would hide it
from Pi 3 users if/when Pi Imager flips Pi 3 to `matching_type:
exclusive` or adds a bitness filter.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@sonarqubecloud
Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant