.travis.yml: basic compile and check recipes

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

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