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 https://git.linaro.org/people/naresh.kamboju/test-definitions-robot.git/tree/automated/linux/ui-browser-test which can be run in a single target. And Daniel had run the test https://validation.linaro.org/scheduler/job/1507227 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 https://www.youtube.com/watch?v=IbLNm3LsMaw gave me some inspiration.). 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