On 28/04/17 14:47, Milosz Wasilewski wrote:
On 28 April 2017 at 14:20, Guillaume Tucker email@example.com wrote:
Thanks for your explanation, also sorry if I've somewhat misused the terms job, shell and test. Trying to piece everything together, I've made a small test definition to see how this would all work in practice. Here's a run:
In such case it's easier to use in-line tests for prototyping I guess.
Right, except here I wanted to run a hello.sh script which needed to be downloaded from somewhere, so I created a git repo for that and put the yaml test definition in there as well.
We've tried to indicate this direction in the docs:
Let us know if those guidelines can be expanded or clarified.
Essentially, anything a developer would need to do outside LAVA to be able to run the scripts used in your LAVA tests should be within the scripts themselves. LAVA needs to provide certain pieces of data and some handlers to report test cases but apart from that, the drive is towards portability and away from hidden steps being done by LAVA.
OK, I think I generally understand this. One part I'm not too sure of is claiming that LAVA test scripts should be portable on one hand, and on the other hand that LAVA should not be involved with how test scripts actually manage to run on a system. It sounds to me that it's rather making portability the user's problem, and LAVA will happily schedule any job that can be successfully submitted regardless of whether the test scripts involved would also manage to run on any other system.
I think this is a matter of convention. If your test is only targeting 1 build/os/device and you don't care about sharing the test - no problem. LAVA will happily run your test. But if you plan to re-use the test on different OSes, different shells and different boards, portability becomes an issue.
Yes, so it's up to the user and while it's usually a good thing to write portable scripts LAVA does not enforce any level of portability. I think we all agree on this point :)