Hi NuttX developers, I've been reviewing the NuttX CI build-selection logic in .github/workflows/arch.yml in the context of the recent concerns about GitHub Actions runner consumption.
The current selector explicitly handles ARM, ARM64, RISC-V, simulator, x86, x86_64, and Xtensa labels. Other architecture labels, including AVR, Ceva, HC, MIPS, OpenRISC, Renesas, SPARC, TriCore, Z16, and Z80, fall through the workflow's default branch and retain all 29 Linux architecture-matrix groups. This is conservative and may be intentional. However, some of these architectures have existing coverage in the testlists, although several are combined in the other group rather than represented by dedicated matrix groups. Any optimization would therefore need to respect the actual testlist coverage rather than assume a one-to-one architecture-to-group mapping. I also reviewed the existing multi-area PR handling and ARM-family selection logic. The current implementation already supports grouping multiple STM32 families. Multiple non-STM32 families, mixed STM32/non-STM32 changes, common ARM paths, unknown chip directories, and incomplete file lists conservatively fall back to all ARM groups. Shared public headers, core kernel code, build infrastructure, CI/tooling changes, and unknown paths should similarly retain conservative fallbacks. I would not want to narrow builds based on Area labels alone. A possible first step would be a non-invasive shadow-mode experiment: Keep the existing authoritative build matrix unchanged. Calculate a proposed architecture-aware selection alongside it. Record the selected groups and the reasons for each selection. Compare the existing and proposed matrix sizes. Review differences for potential coverage gaps before changing any CI behavior. This would allow us to evaluate whether more complete architecture-to-build-group mapping could reduce unnecessary matrix executions without compromising existing test coverage. Before proceeding, I'd appreciate maintainer feedback on two questions: Is the current full-matrix fallback for unmapped architectures intentional? Would a shadow-mode experiment that produces proposed selections and comparison data be useful as an initial contribution? The goal is to improve CI selection precision while preserving conservative fallbacks wherever the impact of a change is uncertain. I've completed a investigation of the existing workflows and testlists and can share the supporting audit if useful. Thanks, Arnav Sharma (https://www.linkedin.com/in/arnavsharma990) (https://github.com/arnavsharma990) ()
