[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