On 12 June 2017 at 01:12, Arthur She arthur.she@linaro.org wrote:
Milosz, As I mentioned this test definition is not yet finished. And it will be used for running all robot framework tests. Some of them will be run through ssh, for example OP TEE xtest, some of them are not. For the video playback verification, host side will communicate with target side through WebDriver protocol. i.e. robotframework communicates with chromedriver which will be run in the hikey. I know Naresh had made a ui-browser-test which can be run in a single target. And Daniel had run the test successfully with a special built of OE. However, in order to run robotframework in hikey we have to put some extra software packages in the image, plus OpenCV if we want to run video playback verification. Beside that, I am thinking about to improve the algorithm which we used for the judgement of video playback (This video gave me some inspiration.).
Here is another approach that would allow you to test as well the whole display pipeline:
https://chromium.googlesource.com/chromiumos/third_party/autotest/+/master/s...
HTH,
Tomeu
That might consume a lot of storage and computing power, so I think run it on the host side should be a good idea.
Thanks, Arthur
2017-06-09 9:17 GMT-07:00 Milosz Wasilewski milosz.wasilewski@linaro.org:
On 9 June 2017 at 17:00, Arthur She arthur.she@linaro.org wrote:
Thanks Neil for your suggestion.
[cut]
It will be assigned from the MAC address of the network adaptor used by each HiKey, so as long as that does not change, the IP will not conflict. However, the lab team do want to minimise the number of fixed IP addresses used for devices, so this support may only be available on designed HiKeys and the test jobs would need to use device tags.
That means we have to hard code "device : IP address" mapping in somewhere. Either in the test job then pass it to the test definition or in the test definition itself. Because this test definition would be run in validation.l.o and staging.validation.l.o, I'd like to have it flexible enough. I copied the idea from your test job and submitted a multinode test job which pass client IP address through multinode API. It seems it is working fine. Would that be a good idea?
Arthur, I'm wondering why do you need to run the tests via ssh? Is this the same test we discussed at Connect (video capture with robotframework)? If so, the tests run entirely on the target. So there would be no need for the host part.
milosz
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users