Dear Joakim, and all, I think with Murdock 2 the MCU build groups are getting obsolete anyway (right Kaspar?). In Murdock 2 every (sub) tasks/jobs is very small, i.e., single app for distinct boards - but hence lots of them.
Though, there is no need to reorganise the existing groups right away, it might be worth (re)considering if we can reduce the overall number of sub tasks per build to speed up build times and omit redundant tests. We had a very similar idea to yours while testing with Jenkins: namely to pick a representative board per vendor/MCU and only test that one. Assuming that all similar boards will fail or succeed, too. For instance, as you suggested choose one nucleo for L0, L1, F0, F1, and so on - or one Cortex-M0, ..., M3. Best, Sebastian > Am 21.04.2017 um 18:46 schrieb Joakim Nohlgård <joakim.nohlg...@eistec.se>: > > Dear developers, > The build test MCU groups were added as a measure to split the compile test > during CI runs into several smaller runs and to easier get an overview of > what is failing. The initial groups were based on what architectures were > supported in the code base, but when the Cortex-M groups became to large they > were split into smaller groups, where the boards were added somewhat > arbitrarily. > > I would like to change this split to create groups of boards which are likely > to fail together to be in the same group. For example, the Nucleo boards > could be in one or more groups cortexm_nucleo, the SAM boards, nrf, and > kinetis boards would be suitable candidates for other groups. Practically > grouping by each xxx_common source directory makes sense in my opinion. > > The motivation behind this is to make it easier to run local build tests when > working with CPU peripheral drivers or other things which are tightly coupled > with a particular vendor. > > Before I go on and create a proper PR for this change I would like to hear > any opinions on this, to save myself from doing a lot of unnecessary work if > this is a stupid idea. > > Best regards, > Joakim > _______________________________________________ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel Sebastian [mail]: s...@mlng.net [code]: https://github.com/smlng _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
