Message ID | 1379085622-2314-1-git-send-email-alex.bennee@linaro.org |
---|---|
State | New |
Headers | show |
On Fri, Sep 13, 2013 at 04:20:22PM +0100, alex.bennee@linaro.org wrote: > From: Alex Bennée <alex@bennee.com> > > While QEMU already has various continuous integration set-ups in > buildbot and commercial Jenkins setups there is some value in supporting > travis-ci as well. It is well integrated into GitHub work flow and will > trigger on all branch pushes and pull requests. This makes it easier for > an individual to kick off smoke tests on a work-in-progress branch > before eventual submission of patches/pull requests upstream. > > The build matrix is currently split by target architecture because a > full build of QEMU can take some time. This way you get quick feedback > for any obvious errors. > --- > .travis.yml | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > create mode 100644 .travis.yml Looks useful. To get more code coverage, flesh out the build environment: before_install: - git submodule update --init --recursive - sudo apt-get update -qq - sudo apt-get install -qq \ libgtk-3-dev libvte-2.90-dev libiscsi-dev librados-dev \ libvdeplug-dev libseccomp-dev libsdl1.2-dev \ libgnutls-dev libpng12-dev libncurses5-dev \ libpixman-1-dev libssh2-1-dev libspice-server-dev \ libspice-protocol-dev libnss3-dev libusb-1.0-0-dev \ libusbredirparser-dev I didn't test this but went through ./configure and looked up the Ubuntu packages which Travis should have access to. You can check the config.log output to verify that optional components were enabled and the libraries were detected. Stefan
stefanha@gmail.com writes: > > Looks useful. To get more code coverage, flesh out the build > environment: Thanks. Am I dreaming or are there some system image tests somewhere as well?
On Wed, Sep 18, 2013 at 03:35:07PM +0100, Alex Bennée wrote: > > stefanha@gmail.com writes: > > > > > Looks useful. To get more code coverage, flesh out the build > > environment: > > Thanks. Am I dreaming or are there some system image tests somewhere as well? Anthony Liguori's "qemu-test" builds special-purpose Linux test guests: http://git.qemu-project.org/?p=qemu-test.git;a=tree There is also KVM Autotest. These tests can use QEMU or QEMU + libvirt and are more involved (installing real guests). https://github.com/autotest/autotest/wiki/KVM-&-Libvirt-Autotest--Introduction-and-Quickstart Both qemu-test and KVM Autotest are heavy in the sense that they will download 100s of MB. Not sure if they are suitable for Travis CI. Stefan
stefanha@gmail.com writes: > On Wed, Sep 18, 2013 at 03:35:07PM +0100, Alex Bennée wrote: >> >> stefanha@gmail.com writes: >> >> > >> > Looks useful. To get more code coverage, flesh out the build >> > environment: >> >> Thanks. Am I dreaming or are there some system image tests somewhere as well? > > Anthony Liguori's "qemu-test" builds special-purpose Linux test guests: > http://git.qemu-project.org/?p=qemu-test.git;a=tree It looks like this is more the sort of thing I want. Given the first thing I found when playing with QEMU was a regression to one of the system emulations (admittedly not one that's used that often nowadays but it was the default). > <snip> > Both qemu-test and KVM Autotest are heavy in the sense that they will > download 100s of MB. Not sure if they are suitable for Travis CI. Surely a kernel with minimal user-space and running a simple script can be kept under 10Mbs? This is essentially a smoke test to ensure QEMU can still boot a kernel with whatever hardware it's trying to emulate. I'm not sure the core translator needs much more exercising from user space after it's booted up? I guess I should do some coverage profiling to check. The Travis docs do mention a concept of binary packages of test data but it's a little unclear if it could be applied to this problem. There is something about fetching things from Amazon S3. Does the QEMU project have much in the way of hosting facilities or does it rely on commercial users to provide them? I wonder if there is an argument for allowing qemu-test to be added as a submodule of qemu so the test scripts can be accessed directly even if the images are pre-canned and stored somewhere else? Cheers,
On Thu, Sep 19, 2013 at 6:01 PM, Alex Bennée <alex.bennee@linaro.org> wrote: > > stefanha@gmail.com writes: > >> On Wed, Sep 18, 2013 at 03:35:07PM +0100, Alex Bennée wrote: >>> >>> stefanha@gmail.com writes: >>> >>> > >>> > Looks useful. To get more code coverage, flesh out the build >>> > environment: >>> >>> Thanks. Am I dreaming or are there some system image tests somewhere as well? >> >> Anthony Liguori's "qemu-test" builds special-purpose Linux test guests: >> http://git.qemu-project.org/?p=qemu-test.git;a=tree > > It looks like this is more the sort of thing I want. Given the first > thing I found when playing with QEMU was a regression to one of the > system emulations (admittedly not one that's used that often nowadays > but it was the default). > >> <snip> >> Both qemu-test and KVM Autotest are heavy in the sense that they will >> download 100s of MB. Not sure if they are suitable for Travis CI. > > Surely a kernel with minimal user-space and running a simple script can > be kept under 10Mbs? This is essentially a smoke test to ensure QEMU can > still boot a kernel with whatever hardware it's trying to emulate. I'm > not sure the core translator needs much more exercising from user space > after it's booted up? I guess I should do some coverage profiling to > check. > > The Travis docs do mention a concept of binary packages of test data but > it's a little unclear if it could be applied to this problem. There is > something about fetching things from Amazon S3. Does the QEMU project > have much in the way of hosting facilities or does it rely on commercial > users to provide them? > > I wonder if there is an argument for allowing qemu-test to be added as a > submodule of qemu so the test scripts can be accessed directly even if > the images are pre-canned and stored somewhere else? Anthony is the person to ask. I have CCed him. Stefan
diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 0000000..69f60c1 --- /dev/null +++ b/.travis.yml @@ -0,0 +1,19 @@ +language: c +env: + - TARGETS=alpha-softmmu,alpha-linux-user + - TARGETS=arm-softmmu,arm-linux-user + - TARGETS=cris-softmmu + - TARGETS=i386-softmmu,x86_64-softmmu + - TARGETS=lm32-softmmu + - TARGETS=m68k-softmmu + - TARGETS=microblaze-softmmu,microblazeel-softmmu + - TARGETS=mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu + - TARGETS=moxie-softmmu + - TARGETS=or32-softmmu, + - TARGETS=ppc-softmmu,ppc64-softmmu,ppcemb-softmmu + - TARGETS=s390x-softmmu + - TARGETS=sh4-softmmu,sh4eb-softmmu + - TARGETS=sparc-softmmu,sparc64-softmmu + - TARGETS=unicore32-softmmu + - TARGETS=xtensa-softmmu,xtensaeb-softmmu +script: "./configure --target-list=${TARGETS} && make && make check"
From: Alex Bennée <alex@bennee.com> While QEMU already has various continuous integration set-ups in buildbot and commercial Jenkins setups there is some value in supporting travis-ci as well. It is well integrated into GitHub work flow and will trigger on all branch pushes and pull requests. This makes it easier for an individual to kick off smoke tests on a work-in-progress branch before eventual submission of patches/pull requests upstream. The build matrix is currently split by target architecture because a full build of QEMU can take some time. This way you get quick feedback for any obvious errors. --- .travis.yml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 .travis.yml