Neil Williams <codeh...@debian.org> writes:
> On Tue, 27 Aug 2013 14:34:09 +0300
> Fathi Boudra <fathi.bou...@linaro.org> wrote:
>
>> On 27 August 2013 14:17, Neil Williams <codeh...@debian.org> wrote:
>> > It is up to the test writer to put the reboots in the right places.
>> > What we do need to do is document that this is done by having more
>> > than one lava_test_shell blocks in the JSON instead of trying to do
>> > the reboot in the YAML.
>> >
>> >> > bootchart is just a use-case. it needs to set up the OS, reboot
>> >> > to collect data, finally test results are available.
>> >
>> > That is just what LAVA does with two lava_test_shell blocks.
>> >
>> >> Maybe my solution with two test definitions is the right way to do
>> >> it after all. Ideally we could also have a separate action to just
>> >> install packages in the test image, but I think the overhead of
>> >> using a separate lava-test-shell test definition is low enough.
>> >
>> > That can just as easily be a single YAML file.
>>
>> +1 for a single yaml file.
>>
>> I think it's better to keep it at the test definition level. We
>> produce a limited set of rootfs/images, we won't be able to produce
>> test images on demand because there's unlimited possibilities.
>>
>> It seems also more logical to me. Since the test doesn't know which
>> image is used, it's up to the test to set up its prerequisite like
>> dependencies and then run the test itself.
>
> So, for completeness, that works out as:
>
> A YAML file called installer.yaml with
> install:
> deps:
> - bootchart
>
> or, if the test image doesn't raise a usable network interface by default:
> run:
> steps:
> - lava-test-case network-up --shell ifconfig eth0 up
> - lava-test-case package-update --shell apt-get update
> - lava-test-case package-install --shell apt-get -y install bootchart
>
> or similar.
>
> A YAML file called parser.yaml with:
>
> run:
> steps:
> - lava-test-case bootchart-run --shell ./run-bootchart-parser.sh
>
> (Contents of run-bootchart-parser.sh TBD)
>
> A single JSON file with a snippet:
>
> {
> "command": "lava_test_shell",
> "parameters": {
> "testdef_repos": [
> {
> "git-repo":
> "git://git.linaro.org/people/foobar/bootchart-yaml.git",
> "testdef": "installer.yaml"
> }
> ],
> "timeout": 900
> }
> },
> {
> "command": "lava_test_shell",
> "parameters": {
> "testdef_repos": [
> {
> "git-repo":
> "git://git.linaro.org/people/foobar/bootchart-yaml.git",
> "testdef": "parser.yaml"
> }
> ],
> "timeout": 900
> }
> },
>
> All of that is already supported.
>
> The one thing which needs better documentation is that the use of more
> than one lava_test_shell command block in the JSON causes a reboot
> between actions when adding to the testdef_repos array does not:
>
> {
> "command": "lava_test_shell",
> "parameters": {
> "testdef_repos": [
> {
> "git-repo":
> "git://git.linaro.org/people/foobar/bootchart-yaml.git",
> "testdef": "installer.yaml"
> },
> {
> "git-repo":
> "git://git.linaro.org/people/foobar/bootchart-yaml.git",
> "testdef": "parser.yaml"
> }
> ],
> "timeout": 900
> }
> },
Is it possible to have a different timeout value per testdef? In the
last example can 'installer.yaml' have a timeout of 60 and 'parser.yaml'
a timeout of 900?
--
andy
_______________________________________________
linaro-validation mailing list
linaro-validation@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-validation
