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

[Daniel Sangorrin]

Hi Rafael,

> -----Original Message-----
> From: fuego-bounces at lists.linuxfoundation.org [mailto:fuego-bounces at lists.linuxfoundation.org] On Behalf Of Rafael Gago Castano
> Sent: Friday, June 02, 2017 8:26 PM
> To: fuego at lists.linuxfoundation.org
> Subject: [Fuego] Dynamic test board (build node) selection.
> 
> 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.
> 

Thanks Rafael. I was already aware about the labels, and I think Jan-Simon already
tried them (did you Jan-Simon?). We may need to fix some racy code inside fuego
before this works but I like the idea. If you manage to get it working let us know please.

> 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).

If you are going to use LAVA, then the board scheduling can be better done by LAVA.
I thought that the labels approach would be good for when you are not using LAVA. Isn't it?

Thanks,
Daniel