Build Examples Is very slow

[EricB-ADI]

Can we add some more logic so it we just change a single file it doesn't build every single example for every single chip? Most changes are not effecting multiple parts.

Slow workflows make it more likely someone just merges without waiting for a finish.

Few ideas we can look for

• If a periph driver changes we can just use a dependency lookup to see what we need to rebuild. Similar idea for misc, and other drivers. I know we build it as a lib.
• BLE change, only rebuild BLE
• Example changes only need to run the examples.
• Full run should only occur on workflow dispatch.

I have used this action on a different repo checking file changes https://github.com/marketplace/actions/changed-files

[Jake-Carter]

I've started a solution on https://github.com/Jake-Carter/msdk/tree/feat/build_test_optimizations

That workflow is nice. We can clean things up with it.

This leverages the fact that the target micro name is in the filepath. Source folders, meXX files, and rev_XX files are more problematic.

The hardest problem is that there is no dependency mapping between libraries and target micros. For example, if a file is changed in MAXUSB which examples should be re-tested? If we change tmr_reva.c which examples are affected?

I want to avoid hard-coding a bunch of lists. Open to suggestions.

What we have now is slow, but it auto-detects new examples and catches everything

[EricB-ADI]

Kind of a multilevel issue.
A) If we don't know the dependency fall back and build all. We can probably leverage jobs in GitHub to run the subsections in parallel. So something like build AI chips., build BLE, etc. in different jobs so that we get the parallelism of GitHub on top of whatever the script is already doing.
B) We create a dependency list for the build to use