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 <swar...@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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot