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

[Tom Rini]

On Fri, Oct 21, 2016 at 12:24:07PM -0600, Stephen Warren wrote:
> 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).

I don't like this part either.  I couldn't find an "official" PPA to
provide a newer qemu nor does it appear to be in the official backports
channel either.  My current plan is that if something happens to the PPA
I'll have to host one myself.

> >+ # 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?

A good point.  The way I've been thinking of it is that we also need a
repo with as many and varied configs as possible, which has become yours
:).  That said, we could move a copy of this over to the u-boot account
on github if you'd like.

> 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.

A good point.  I think we could get the network tests going, maybe with
a little re-work to dynamically hash the file from the host side?  But
that's an aside.

> >+    - 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.

So, the way travis-ci works is that you can (and we do) split tasks up
to run in parallel.  The hunk above is a series to run in sequence on
the same host. The downside to moving this to parallel is the amount of
duplication you need in each stanza.  We could fix that (at least in the
case of non-buildman-fetched toolchains) if test.py used buildman to
build, as that will determine CROSS_COMPILE correctly from the default
.buildman file we create earlier on.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161022/b925ed29/attachment.sig>