[Fuego] RFC: Refactoring post_test

Daniel Sangorrin daniel.sangorrin at toshiba.co.jp
Mon Mar 27 01:00:38 UTC 2017


Hi Tim,

> -----Original Message-----
> From: fuego-bounces at lists.linuxfoundation.org [mailto:fuego-bounces at lists.linuxfoundation.org] On Behalf Of Bird, Timothy
> I have added a new function: test_cleanup
> This function is called by post_test during the post_test phase, and is used to clean up after the test
> (for anything that Fuego doesn't clean up).  It is optional, so not every test needs to have one.

I've checked the code. At the moment, target_cleanup and target_precheck are being called through 'call_if_present'.
Example: 'call_if_present test_cleanup'

Ref: https://bitbucket.org/tbird20d/fuego-core/src/84df2212bd66f2fa34e2b6b06fdd583553d626bd/engine/scripts/functions.sh?at=next&fileviewer=file-view-default

A problem with that is that despite they are optional from the test writer's point of view, they are not
from the Fuego user's point of view.

I suggest that we use the same pattern we used for Target_PostCleanup, so that the user is able to
enable or disable the execution of test_cleanup () from the testplan or Jenkins (configure).
[Note] The typical use case here is a user that wants to inspect what went wrong with a test manually.

[ "$Target_PostCleanup" = "true" ] && target_cleanup $1 || true

> Currently, it is only used to kill possibly-still-running processes on the target board.  All uses of it
> in my 'next' branch only call 'kill-procs'.  kill_procs is a new fuego function, that does what its name implies.
> It uses the already existing ov_rootfs_kill() function, that post_test used to call directly.
> 
> As an example, here is the test_cleanup from Benchmark.lmbench2:
> function test_cleanup {
>     kill_procs lmbench lat_mem_rd par_mem
> }
> 
> I can imaging putting other things in test_cleanup, like restoring device configurations, unmounting filesystems,
> cleaning up other directories (outside the ones Fuego already cleans up) or doing additional log post-processing.
> (For example, maybe the new LTP excel spreadsheet creation could go here instead of in the test_run function.)

Actually, the excel sheet is generated in test_processing not in test_run.
 
> Note that this architecture implies that test_run itself can be interrupted (possibly by a timeout), and that the
> base script will continue to run so it can perform the post_test operation.  I believe a signal handler needs
> to be implemented to support this behavior.  It's not there now.

That sounds great. 

Thanks,
Daniel




More information about the Fuego mailing list