From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hms365.onmicrosoft.com; s=selector1-hms-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ClUD/FkvFhhLRIG4+qtCDIJ24nljZK2XgN2xMh5+twI=; b=MyTJflHEwH64atPaikEI265seuIAURKHFYP+C2PBb4eLNR+wmJm2wSgP/Q2aoixlt9q0U6Tylf8voPko+sM4o9e6LFpMOpw9ktemM/NDP2k7zYsXnk25WIETQlxH92glsCqOwvzeGhldc3t3xrzqD0XX5R8iMtDiQMGoVJJ/lFk= From: Rafael Gago Castano Date: Fri, 12 May 2017 14:33:42 +0000 Message-ID: References: , , , In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Fuego] First steps with fuego List-Id: Mailing list for the Fuego test framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Bird, Timothy" Cc: "fuego@lists.linuxfoundation.org" As I have no infinite budget to investigate fuego, I decided to skip lookin= g at that signal error on "ls" and to assume that we can do communication t= ests with fuego, it may need some refinements but there isn't any big barri= er. As a matter of fact for our use case it's simpler than by using LAVA m= ultinode tests. Then I started looking at the device "power off + power off + flashing + wa= it for boot" procedure. I tried to do it as a test but it had a problem, wh= en the device is rebooting it hasn't connectivity, so it does fail: SDKTARGETSYSROOT=3D/opt/slp/dingo-next/sdk/sysroots/cortexa9hf-neon-oe-linu= x-gnueabi Target_PreCleanup=3Dtrue _=3D/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 jus= t adding an optional "setup" and "teardown" functions to the board file cou= ld be a good starting point. Then the problem would be to decide when to run them. Running them as a tes= t (of a new type) makes very explicit to see and control when they run. Hav= ing them on the board file would need rules or maybe flags for "ftc", becau= se 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 t= he Jenkins side and let the user handle the integration. This makes the use= r to have more scattered configuration (configure boards in two places) but= keeps Fuego simpler. I'm not very fluent with Jenkins hacking but it seem= s doable too. Which approach seems the best?