[Linaro-validation] 2012.05 planning: Move existing test defintions away from LAVA test to a dedicated project
yongqin.liu at linaro.org
Thu Jun 14 06:57:57 UTC 2012
On 3 April 2012 03:45, Paul Larson <paul.larson at linaro.org> wrote:
> So what you are suggesting is basically that *all* tests become
> out-of-tree tests?
To some extent, I +1 for making more test become out-of-tree test too.
Let say integrating an android test into lava-android-test:
1. android team member create the test tools
sometimes the test tools just an android shell script, but it also need
to merged into lava-android-test
2. android team member understand the lava wrapper infrastructure
3. android team member need to understand python to write the python
It's very very simple for member who know python, but will be difficult
for member who does not know python.
like the indent style, string format style, for/if sentence style
4. android team member need to submit a MP for the branch, and wait
5. android member need to wait lava-android-test deployed to production and
then can try the test on production.
some times also need to wait the modification of android build.
And all the steps above will need LAVA member to support.
If we make the test out-of-tree, then we just need to define the rules for
the test tools that lava support,
and android team member just need create the test tools obey the rules lava
They can use any language the like, shell, python, C, even assemble
language if he like
And the monkeyrunner supported now in the lava-android-test is something
android team member only need to create the monkeyrunner script obey the
rule and commit it into their git.
then they can try the test from android build.
> Also, some of your rationale is around lava being cross-platform.
> Lava-test - which natively assumes ubuntu/debian is certainly not
> cross-platform. Also, how would this affect lava-android-test?
> I actually think we need to rethink lava-android-test, lava-test, etc.
> This is, perhaps, a good blueprint topic for the next connect. There have
> been some who have even expressed interest in running host-side tests for
> things like bootloader testing, prompting previous discussions of yet
> another lava-test fork. This is kinda nuts to keep forking this thing.
> I'd really like to go back to a base framework and reconsider things that
> we thought were a priority in the original design.
> I'm thinking that all of this can be driven from the host side. A
> transport could be established and specified and handed off to lava-test to
> drive the install steps, run steps, etc. It could be serial, ssh, adb,
> lava-client, whatever. Then parsing/bundling would happen host-side. Test
> definitions could possibly even be simplified a bit I think.
> On Mon, Apr 2, 2012 at 9:57 AM, Zygmunt Krynicki <
> zygmunt.krynicki at linaro.org> wrote:
>> W dniu 02.04.2012 16:30, Andy Doan pisze:
>> > On 04/02/2012 07:20 AM, Zygmunt Krynicki wrote:
>> >> Hi, please have a look at  and discuss this on the mailing list.
>> >> 
>> > I would prefer this stay as one project, but the "test_definitions"
>> > directory is thought of as a separate component that another team,
>> > Paul's, manage (bug triage, code review, and merge)
>> AFAIK there is no way to implement that on launchpad without spamming
>> everyone in the LAVA part of the team. Plus it does not address any of
>> the other issues I've raised. It certainly is not a single project for
>> the reasons I've outlined there.
>> > I think keeping this simplicity is important.
>> I don't think this will raise the complexity, if anything it will ensure
>> that the same level of user experience is provided to in-tree and
>> out-of-tree tests.
>> Zygmunt Krynicki
>> Linaro Validation Team
>> linaro-validation mailing list
>> linaro-validation at lists.linaro.org
> linaro-validation mailing list
> linaro-validation at lists.linaro.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the linaro-validation