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.
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.
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.
IMO a good idea. And as Sebastian pointed out, the build groups
themselves will be obsolete, soon.
How about introducing tags? The difference being that a board can have
more than one "tag", with some of them possibly defined by the MCU used.
e.g., every nucleo gets "nucleo", "arm" and "cortex-m", but some also
get "cortex-m0" and maybe "lowmem", others get "cortex-m4" and
"hardfloat". You get the idea.
That way we could use our buildtests like:
$ make buildtest TAGS=msp430
or even
$ make buildtest TAGEXPR="cortex-m0 and nucleo"
It might be that this is equivalent to what we now call "features".
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.
IMO a good idea. And as Sebastian pointed out, the build groups
themselves will be obsolete, soon.
How about introducing tags? The difference being that a board can have
more than one "tag", with some of them possibly defined by the MCU used.
e.g., every nucleo gets "nucleo", "arm" and "cortex-m", but some also
get "cortex-m0" and maybe "lowmem", others get "cortex-m4" and
"hardfloat". You get the idea.
That way we could use our buildtests like:
$ make buildtest TAGS=msp430
or even
$ make buildtest TAGEXPR="cortex-m0 and nucleo"
It might be that this is equivalent to what we now call "features".
A good idea, we could introduce just introduce more features and wire
the features_required checks to be available from the command line.
`make buildtest TAGS=kinetis`
would be very useful while working on periph drivers.
