ci: build the KC110 and the Tapo TC70 v3 instead of skipping them

[openipc-ai]

Both devices have had a complete devices/<dir>/ in this tree for a long time and have never once been built. #120 froze that state rather than changing it — it put the 7 defconfigs that were in no master.yml matrix into NOT_BUILT so that a device falling out of CI would be a test failure instead of a silent skip. Freezing was right for a change whose job was to not alter what gets built; it was never meant to be permanent for devices whose only problem is that nobody added the matrix line.

Two contributors did try to add that line. #111 (Tapo TC70 v3, July) and #108 (KC110, June) both append to the device list in master.yml, which is where the registry lived when they were written. It does not live there any more — the matrix is read off the tree — so both PRs are merge conflicts now, and the devices they asked for are exactly the two entries removed here.

This is their CI half, landed the way the selector wants it. #108 also carries a BR2_OPENIPC_MAJESTIC="ultimate" line and a vendor libsns_ov2735.so for the no-video bug; those are unaffected by any of this and stay with that PR.

Self-test

The two cases that used t31_lite_tp-link-tapo-tc70-v3 as their example of an unbuilt device move to t31_lite_xiaomi-mjsxj05hl, which is still in NOT_BUILT. The overlay case also switches to a path that exists, since the device it now names has no etc/inittab.

$ python3 .github/scripts/ci-matrix.py --self-test
ci-matrix: self-test ok (109 devices, 15 smoke, 39 cases)

Before, both devices reached nothing; now each narrows to itself:

$ echo devices/hi3518ev200_ultimate_tplink-kasa-kc110/general/overlay/usr/bin/load_hisilicon \
    | python3 .github/scripts/ci-matrix.py --stdin
ci-matrix: 1/109 devices (needs_build=True) --- narrowed to the affected devices
  hi3518ev200_ultimate_tplink-kasa-kc110

Note on cost

Neither device has ever been through a build, so this PR is where we find out. That is affordable exactly once: a change to ci-matrix.py cannot narrow — it is what does the narrowing — so this runs the full 109-device matrix and proves both of them in the same run.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Build KC110 and Tapo TC70 v3 in CI

✨ Enhancement 🧪 Tests ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Enables CI builds for KC110 and Tapo TC70 v3 devices.
• Preserves unbuilt-device coverage using the still-excluded Xiaomi MJSXJ05HL.
• Aligns device registration with tree-derived matrix discovery.

Diagram

graph TD
  A["Changed paths"] --> B["Device discovery"] --> C{"Excluded device?"}
  C -->|No| D["Build matrix"] --> E["KC110 and TC70"]
  C -->|Yes| F["Skip build"]
  G["Self tests"] -.-> B

Loading

High-Level Assessment

The PR uses the repository's current tree-derived registry correctly: removing the two stale NOT_BUILT exemptions is the minimal way to activate these complete device definitions. Reintroducing explicit workflow matrix entries was considered but would duplicate device registration and conflict with the selector's source-of-truth design.

Files changed (1) +4 / -5

Enhancement (1) +4 / -5

ci-matrix.pyEnable KC110 and TC70 builds in the CI selector +4/-5

Enable KC110 and TC70 builds in the CI selector

• Removes KC110 and Tapo TC70 v3 from the explicit NOT_BUILT set so tree discovery includes them in CI. Replaces their unbuilt-device self-test fixtures with Xiaomi MJSXJ05HL paths, preserving defconfig and overlay exclusion coverage.

.github/scripts/ci-matrix.py

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can ask Qodo to dismiss a finding you disagree with, with your reason on record

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗