On Wed, Mar 31, 2021, at 11:26, Nathan Hartman wrote: > I wonder if we need the tests to be a bit smarter in restricting what they > test. > > For example if the change only affects files in arch/arm/stm32h7 then only > stm32h7 configs will be tested.
That can be difficult to do. A header might define something that ultimately reaches hardware-specific code and make it fail. My reasoning with the per board+config ccache is that it should more or less detect something like this without hardcoding any rules: only files that are impacted by any changes in the current PR would be rebuilt, any other file would be instantanously obtained from cache. This is mostly what I observe when I use ccache locally: going to make menuconfig indeed rebuilds everything, but it is quite faster than an initial build with 100% miss rate. We should also eventually check if we're not adding some cache-breaking definition (encode the date of the build in nuttx/config.h for example). > > Also if the PR only affects Documentation then there's no need to build any > board configs. That's already being done. Any chances contained under Documentation/ only rebuild docs. > > Changes in areas like sched will affect all configs so the tests cannot be > restricted. But it seems to me that most PRs are in arch, so even if some > PRs still have to run the full set of tests, it will still be a big > optimization. > > Nathan >
