Re: [Fuego] First steps with fuego

From: Rafael Gago Castano <RGC@hms.se>
To: "Bird, Timothy" <Tim.Bird@sony.com>
Cc: "fuego@lists.linuxfoundation.org" <fuego@lists.linuxfoundation.org>
Subject: Re: [Fuego] First steps with fuego
Date: Fri, 12 May 2017 14:33:42 +0000	[thread overview]
Message-ID: <HE1PR06MB30365DD87F5942695ED855B7C2E20@HE1PR06MB3036.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <HE1PR06MB3036959D51FD5FBFC02208C8C2ED0@HE1PR06MB3036.eurprd06.prod.outlook.com>

As I have no infinite budget to investigate fuego, I decided to skip looking at that signal error on "ls" and to assume that we can do communication tests with fuego, it may need some refinements but there isn't any big barrier.  As a matter of fact for our use case it's simpler than by using LAVA multinode tests.

Then I started looking at the device "power off + power off + flashing + wait for boot" procedure. I tried to do it as a test but it had a problem, when the device is rebooting it hasn't connectivity, so it does fail:

SDKTARGETSYSROOT=/opt/slp/dingo-next/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi
Target_PreCleanup=true
_=/usr/bin/env
ssh: connect to host 192.168.1.2 port 22: No route to host
ssh: connect to host 192.168.1.2 port 22: No route to host

*** ABORTED ***

Fuego error reason: Cannot connect to 192.168.1.2 via ssh

in signal_handler
##### doing fuego phase: post_test ########

I guess that to do "power off + power off + flashing + wait for boot" would require a different approach than writing a test.

At first I thought about having two new types of tests: setup and teardown, but these aren't conceptually tests. IMO these belong to the board, so just adding an optional "setup" and "teardown" functions to the board file could be a good starting point.

Then the problem would be to decide when to run them. Running them as a test (of a new type) makes very explicit to see and control when they run. Having them on the board file would need rules or maybe flags for "ftc", because the setup/teardown functions should definitely run as the first and last actions of a testplan/batch, but they would be detrimental when developing tests.

Then the third approach would be to leave the board setup and teardown to the Jenkins side and let the user handle the integration. This makes the user to have more scattered configuration (configure boards in two places) but keeps Fuego simpler. I'm not very fluent  with Jenkins hacking but it seems doable too.

Which approach seems the best?