Hi Arnav, Thank you for taking the time to help the project!
+1 If even that doesn't alleviate the issue, we need to select only a single board from each arch/family and test only that one. The guy from ASF didn't reply to Tomek's request about more GitHub Jobs, so I think we won't get them. We need each PR to finish fast, ideally in less than 20 minutes! I think it is feasible! BR, Alan On Sat, Oct 31, 2026 at 11:27 AM Arnav Sharma <[email protected]> wrote: > 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) ()
