[Fuego] Dynamic test board (build node) selection.

Rafael Gago Castano RGC at hms.se
Fri Jun 2 11:26:20 UTC 2017


Hello.

I just write this to make everyone aware/share knowledge. You may very well be
aware of this.

On each jenkins node there is a field called labels. Where one can define
various labels, let's say that we define this for a given node: 

"this-node-board-type has-gps has-3g-modem".

These labels can be used by Jenkins to dynamically enqueue jobs to a slave:
https://michael-prokop.at/blog/2014/03/01/jenkins-on-demand-slave-selection-through-labels/

If the board type would be just a label and the variables inside the fuego board
file would be defined as jenkins build node environment variables instead, this
could be acomplished:

-We would have just one jenkins project per test and spec (if specs are still
 necessary after having fully parameterized builds).
-We would have dynamic board allocation to do tests in parallel on many boards.

Then the extra labels could be control optional test features. For example a 
"gps" test could require the "has-gps" flag and Jenkins would only dispatch the
job to a board with the "has-gps" tag.

As a matter of fact, this is how things work in LAVA, but in the fuego case the
heavy lifting is already done by jenkins.

This of course would require breakage and is only suitable for fuego v2. With
this would force a redesign of "TARGET_SETUP_LINK" and "TARGET_TEARDOWN_LINK",
ftc and maybe force the need to do device integration (flashing and booting) a
first class fuego citizen (IMO the integration should be left to the user and
fuego should only provide hooks).


More information about the Fuego mailing list