On 03/09/2012 01:59 PM, Zach Pfeffer wrote:
Then all you need is one monkey with all the parameters exposed. Everything else will be specified by the dispatcher job. You can specify targets and any parameters.
monkey is just an example of a command. The commands could be anything in the command file:
command1 param1 command2 param2 etc...
You are attempting to solve a non-issue. We have everything needed to support your use case now.
I don't think so based on the feedback Pauls given me. My issue is, run through a set of commands that individually may fail and if one fails reboot the unit and keep going on the next command, recording the output from all runs.
I believe Paul thinks there's a way to handle reboots (or it could be written) between LAVA tests. So could we compromise with something like this:
Make each test that's known to cause Android to reboot as its own lava-android-test. Put the other commands, that need to be run that don't cause reboots into one lava-android-test. This probably works best if the majority of what you want doesn't cause reboots. So lets pretend we have 4 commands:
* bam * foo * bar * blah
If "bam" is the only one that causes a reboot, we make it its own lava-android-test. We could submit LAVA jobs that call the "bam" test with different parameters. So bam1, bam2, and bam3 tests could be attempted.
We then have one lava-android-test that runs "foo", "bar", and "blah". Again, this could call these with different parameters.
So in the end you could have a LAVA job that could exercise all the tests in any order with any set of parameters. These tests could also still be run independently of LAVA on Android for developers not interested in LAVA.
-andy