The verification layer of images/esp-idf never asks gcovr for its version, so a
failed or partial install of it publishes a green build.
images/esp-idf/Dockerfile:34 — gcovr is installed through apt, in the same
list as jq.
images/esp-idf/README.md:21 — the README promises it to the user:
**gcovr** - Code coverage reporting.
images/esp-idf/Dockerfile:96-107 — the verification RUN prints python,
pytest, esptool, jq and idf.py. Not gcovr.
Why it matters
CLAUDE.md states the rule this falls out of:
Every image sets WORKDIR /workspace and ends with a version-printing
verification RUN as its last build layer. It is the only thing standing between
a silently failed install and a published image: a tool that never installed
still leaves a green build until something asks it for its version. A mirror
serving a stale package, or an installer that exits 0 on a partial install,
produces exactly that.
jq is asked. gcovr is not, and it is the one the README advertises as a
capability rather than as plumbing.
The fix
One line in the verification RUN:
No version assertion is wanted. gcovr arrives through apt, and apt is
deliberately unpinned in this repository (scripts/check-pins.sh, and the pins
section of CLAUDE.md), so printing is the whole of what the rule asks for here.
The same gap is wider in platformio
Worth closing in the same change, since it is one rule and one kind of edit.
images/platformio/Dockerfile:23 installs build-essential, pkg-config,
cmake, clang-format, git, curl, wget and jq; its verification layer
(pio --version, python --version, gcc --version, pio platform list) covers
only the compiler out of that list. cmake, clang-format, git and jq are all
tools a user invokes by name, and images/platformio/README.md lists them.
The other two images are already clean:
images/host prints every tool it installs — gcc, cmake, ninja, git, jq, ccache,
python3, ruff, mypy, pytest, lychee, docker, clang-format, clang-tidy.
images/esp-matter installs only build libraries through apt (libssl-dev,
libdbus-1-dev, libglib2.0-dev, libavahi-client-dev, python3-dev,
pkg-config) — nothing there has a version to print.
Source
Found by a reviewer during #31
(the pytest-embedded 2.9.3 bump) and left out of it as unrelated to the harness.
Pre-existing, not a regression: nothing is broken today, and the trigger that makes
it matter is a mirror serving a broken package on some future rebuild.
The verification layer of
images/esp-idfnever asksgcovrfor its version, so afailed or partial install of it publishes a green build.
images/esp-idf/Dockerfile:34—gcovris installed through apt, in the samelist as
jq.images/esp-idf/README.md:21— the README promises it to the user:**gcovr** - Code coverage reporting.images/esp-idf/Dockerfile:96-107— the verificationRUNprints python,pytest, esptool, jq and
idf.py. Notgcovr.Why it matters
CLAUDE.md states the rule this falls out of:
jqis asked.gcovris not, and it is the one the README advertises as acapability rather than as plumbing.
The fix
One line in the verification
RUN:No version assertion is wanted.
gcovrarrives through apt, and apt isdeliberately unpinned in this repository (
scripts/check-pins.sh, and the pinssection of CLAUDE.md), so printing is the whole of what the rule asks for here.
The same gap is wider in platformio
Worth closing in the same change, since it is one rule and one kind of edit.
images/platformio/Dockerfile:23installsbuild-essential,pkg-config,cmake,clang-format,git,curl,wgetandjq; its verification layer(
pio --version,python --version,gcc --version,pio platform list) coversonly the compiler out of that list.
cmake,clang-format,gitandjqare alltools a user invokes by name, and
images/platformio/README.mdlists them.The other two images are already clean:
images/hostprints every tool it installs — gcc, cmake, ninja, git, jq, ccache,python3, ruff, mypy, pytest, lychee, docker, clang-format, clang-tidy.
images/esp-matterinstalls only build libraries through apt (libssl-dev,libdbus-1-dev,libglib2.0-dev,libavahi-client-dev,python3-dev,pkg-config) — nothing there has a version to print.Source
Found by a reviewer during #31
(the pytest-embedded 2.9.3 bump) and left out of it as unrelated to the harness.
Pre-existing, not a regression: nothing is broken today, and the trigger that makes
it matter is a mirror serving a broken package on some future rebuild.