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

Bird, Timothy Tim.Bird at sony.com
Sat Jun 3 03:29:53 UTC 2017

> -----Original Message-----
> From: Rafael Gago Castano on Friday, June 02, 2017 8:26 PM
> 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.

I'm not as familiar with Jenkins labels as Daniel is, but this sounds similar
to what we're trying to achieve with Fuego's new dynamic variables and
dependency system.   The idea is that a board file has dynamic
variables (that are automatically detected) in


and tests can specify:

And Fuego will know whether those tests can run or not.

Right now (well, in v2), Fuego just checks these at test startup and aborts.
Longer term, it is intended to be able to statically analyze the tests and select
them for execution, based on their dependencies.

> This of course would require breakage and is only suitable for fuego v2. With
> this would force a redesign of "TARGET_SETUP_LINK" and
> 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).

We intend to support flashing and booting as first-class Fuego operations
in the future. Provided as hooks as you describe, with samples for various
existing methods and tools.
 --- Tim

More information about the Fuego mailing list