[U-Boot] [PATCH v2 8/8] travis-ci: Add test.py for various qemu platforms

[Stephen Warren]

On 10/20/2016 01:40 PM, Tom Rini wrote:
> - Add a PPA for a more recent qemu (required for PowerPC to work)
> - Add tests to run test.py for various QEMU platforms.  This relies on
>   swarren's uboot-test-hooks repository to provide the abstractions.

Overall, the series,
Acked-by: Stephen Warren <swarren at nvidia.com>

A few comments on this particular patch below:

> diff --git a/.travis.yml b/.travis.yml

>  addons:
>    apt:
> +    sources:
> +    - sourceline: 'ppa:gns3/qemu'

Have you co-ordinated with "qns3" to ensure that PPA is always going to 
be available, and host binaries for Ubuntuy 16.04 (some PPAs eventually 
disappear as the owner moves on to other things, or change the set of 
distro releases they support at the owner's whim).

> + # Clone uboot-test-hooks
> + - git clone --depth=1 git://github.com/swarren/uboot-test-hooks.git /tmp/uboot-test-hooks

Does it make sense to rely on my copy of the repo being around all the 
time? I have no intention of removing it, but when I created it I'd 
assumed others would create their own clones for their own 
infra-structure. I wonder if all the dependencies for U-Boot's testing 
should be hosted on U-Boot infra-structure?

That all said, this should be fine; just something to ponder.

> + - ln -s travis-ci /tmp/uboot-test-hooks/bin/`hostname`

It may be useful to add the following too:

- ln -s travis-ci /tmp/uboot-test-hooks/py/`hostname`

That way, if we ever need per-board test configuration files, the path 
to access them will already be available.

> +    - env:
> +        - CROSS_COMPILE="/usr/bin/arm-linux-gnueabihf-"
> +      script:
> +        - ./test/py/test.py --bd vexpress_ca15_tc2 --id qemu --build;
> +          ./test/py/test.py --bd vexpress_ca9x4 --id qemu --build;
> +          ./test/py/test.py --bd integratorcp_cm926ejs --id qemu --build;

Does it make sense to make that 3 separate scripts? I assume that would 
(a) allow the individual status of the 3 test.py invocations to be seen 
separately (b) might allow/cause travis-ci to run them in parallel; I'm 
not sure if this Travis config file is a sequential list of commands, or 
a list of potentially parallel actions.