[v3] .cirrus.yml: basic compile and test for FreeBSD

From: Ed Maste <emaste@freebsd.org>

Signed-off-by: Ed Maste <emaste@freebsd.org>
---
Changes since v2:
  * remove fontconfig and freetype2, noted by Thomas Huth

After this patch is applied someone with appropriate permissions will
need to add the Cirrus-CI application in GitHub.

 .cirrus.yml | 16 ++++++++++++++++
 MAINTAINERS |  8 ++++++++
 2 files changed, 24 insertions(+)
 create mode 100644 .cirrus.yml

On 2019-01-18 15:47, emaste@freebsd.org wrote:
> From: Ed Maste <emaste@freebsd.org>
> 
> Signed-off-by: Ed Maste <emaste@freebsd.org>
> ---
> Changes since v2:
>   * remove fontconfig and freetype2, noted by Thomas Huth
> 
> After this patch is applied someone with appropriate permissions will
> need to add the Cirrus-CI application in GitHub.

Maybe even more important: It also works for forked repositories (once
you've enabled the Cirrus-CI application from the marketplace), so
people can use this to test their branches before sending PULL requests,
e.g.:

 https://cirrus-ci.com/github/huth/qemu

Thus this sounds like a good idea to me.

Reviewed-by: Thomas Huth <thuth@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>

>  .cirrus.yml | 16 ++++++++++++++++
>  MAINTAINERS |  8 ++++++++
>  2 files changed, 24 insertions(+)
>  create mode 100644 .cirrus.yml
> 
> diff --git a/.cirrus.yml b/.cirrus.yml
> new file mode 100644
> index 0000000000..84d6f0519b
> --- /dev/null
> +++ b/.cirrus.yml
> @@ -0,0 +1,16 @@
> +freebsd_12_task:
> +  freebsd_instance:
> +    image: freebsd-12-0-release-amd64
> +    cpu: 8
> +    memory: 24G
> +  env:
> +    CIRRUS_CLONE_DEPTH: 1
> +  install_script: pkg install -y
> +    bison curl cyrus-sasl git glib gmake gnutls
> +    nettle perl5 pixman pkgconf png usbredir
> +  script:
> +    - mkdir build
> +    - cd build
> +    - ../configure || { cat config.log; exit 1; }
> +    - gmake -j8 V=1
> +    - gmake -j8 V=1 check
> diff --git a/MAINTAINERS b/MAINTAINERS
> index af339b86db..f9da8c9cf0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2483,6 +2483,14 @@ W: https://travis-ci.org/qemu/qemu
>  W: https://app.shippable.com/github/qemu/qemu
>  W: http://patchew.org/QEMU/
>  
> +FreeBSD Hosted Continuous Integration
> +M: Ed Maste <emaste@freebsd.org>
> +M: Li-Wen Hsu <lwhsu@freebsd.org>
> +L: qemu-devel@nongnu.org
> +S: Maintained
> +F: .cirrus.yml
> +W: https://cirrus-ci.com/github/qemu/qemu
> +
>  Guest Test Compilation Support
>  M: Alex Bennée <alex.bennee@linaro.org>
>  R: Philippe Mathieu-Daudé <f4bug@amsat.org>
>

On 2019-01-21 10:13, Thomas Huth wrote:
> On 2019-01-18 15:47, emaste@freebsd.org wrote:
>> From: Ed Maste <emaste@freebsd.org>
>>
>> Signed-off-by: Ed Maste <emaste@freebsd.org>
>> ---
>> Changes since v2:
>>   * remove fontconfig and freetype2, noted by Thomas Huth
>>
>> After this patch is applied someone with appropriate permissions will
>> need to add the Cirrus-CI application in GitHub.
> 
> Maybe even more important: It also works for forked repositories (once
> you've enabled the Cirrus-CI application from the marketplace), so
> people can use this to test their branches before sending PULL requests,
> e.g.:
> 
>  https://cirrus-ci.com/github/huth/qemu
> 
> Thus this sounds like a good idea to me.
> 
> Reviewed-by: Thomas Huth <thuth@redhat.com>
> Tested-by: Thomas Huth <thuth@redhat.com>

Actually, scratch that Tested-by: My build timed out after 1 hour:

 https://cirrus-ci.com/task/5113243459649536

I think you need to split it up  / only build a subset of the targets
with the --target-list of the configure script, to make sure that the
task always finishes in < 1 h.
Something similar is also done in .travis.yml already, and I am also had
to split it up for my gitlab-ci.yml, see here:

 https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg00226.html

Are you also sure that you can run with 8 CPUs here? ... I somehow doubt
that, otherwise the build should not take more than 1 h, I think.

 Thomas

emaste@freebsd.org writes:

> From: Ed Maste <emaste@freebsd.org>
>
> Signed-off-by: Ed Maste <emaste@freebsd.org>
> ---
> Changes since v2:
>   * remove fontconfig and freetype2, noted by Thomas Huth
>
> After this patch is applied someone with appropriate permissions will
> need to add the Cirrus-CI application in GitHub.

I should be able to add CirrusCI to the QEMU project github when we
merge. I see there is another revision coming in so I''ll wait for that
before I queue it up.

>  .cirrus.yml | 16 ++++++++++++++++
>  MAINTAINERS |  8 ++++++++
>  2 files changed, 24 insertions(+)
>  create mode 100644 .cirrus.yml
>
> diff --git a/.cirrus.yml b/.cirrus.yml
> new file mode 100644
> index 0000000000..84d6f0519b
> --- /dev/null
> +++ b/.cirrus.yml
> @@ -0,0 +1,16 @@
> +freebsd_12_task:
> +  freebsd_instance:
> +    image: freebsd-12-0-release-amd64
> +    cpu: 8
> +    memory: 24G
> +  env:
> +    CIRRUS_CLONE_DEPTH: 1
> +  install_script: pkg install -y
> +    bison curl cyrus-sasl git glib gmake gnutls
> +    nettle perl5 pixman pkgconf png usbredir
> +  script:
> +    - mkdir build
> +    - cd build
> +    - ../configure || { cat config.log; exit 1; }
> +    - gmake -j8 V=1
> +    - gmake -j8 V=1 check
> diff --git a/MAINTAINERS b/MAINTAINERS
> index af339b86db..f9da8c9cf0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2483,6 +2483,14 @@ W: https://travis-ci.org/qemu/qemu
>  W: https://app.shippable.com/github/qemu/qemu
>  W: http://patchew.org/QEMU/
>
> +FreeBSD Hosted Continuous Integration
> +M: Ed Maste <emaste@freebsd.org>
> +M: Li-Wen Hsu <lwhsu@freebsd.org>
> +L: qemu-devel@nongnu.org
> +S: Maintained
> +F: .cirrus.yml
> +W: https://cirrus-ci.com/github/qemu/qemu
> +
>  Guest Test Compilation Support
>  M: Alex Bennée <alex.bennee@linaro.org>
>  R: Philippe Mathieu-Daudé <f4bug@amsat.org>


--
Alex Bennée

On Mon, 21 Jan 2019 at 05:18, Thomas Huth <thuth@redhat.com> wrote:
>
> Actually, scratch that Tested-by: My build timed out after 1 hour:
>
>  https://cirrus-ci.com/task/5113243459649536

Interesting. My build reports successful completion after a bit under
1/2 hr: https://cirrus-ci.com/build/5717787416723456

I notice that both your failing result and my successful result have
as the last test:

PASS 57 test-hmp /aarch64/hmp/none+2MB

so I wonder if yours actually finished in 1/2 hr, but then waited for
1/2 hr on something that got stuck?

> Are you also sure that you can run with 8 CPUs here? ... I somehow doubt
> that, otherwise the build should not take more than 1 h, I think.

To confirm, I have another build running now with
echo "Running with hw.ncpu=$(sysctl -n hw.ncpu)"
added.

On Mon, 21 Jan 2019 at 06:03, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> I should be able to add CirrusCI to the QEMU project github when we
> merge. I see there is another revision coming in so I''ll wait for that
> before I queue it up.

Do you mean my eadd119 commit "cirrus: tail dmesg to see if this is
due to OOM"? I didn't intend to submit that (at least not in exactly
the current form); I added it while looking at what I believe was a
transient Cirrus failure.

Ed Maste <emaste@freebsd.org> writes:

> On Mon, 21 Jan 2019 at 06:03, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> I should be able to add CirrusCI to the QEMU project github when we
>> merge. I see there is another revision coming in so I''ll wait for that
>> before I queue it up.
>
> Do you mean my eadd119 commit "cirrus: tail dmesg to see if this is
> due to OOM"? I didn't intend to submit that (at least not in exactly
> the current form); I added it while looking at what I believe was a
> transient Cirrus failure.

Ahh no - I thought Thomas had a failure with long build times. However
if it's a hanging test that goes away on retry it's good to go.

--
Alex Bennée

On Mon, 21 Jan 2019 at 10:16, Ed Maste <emaste@freebsd.org> wrote:
>
> To confirm, I have another build running now with
> echo "Running with hw.ncpu=$(sysctl -n hw.ncpu)"
> added.

Confirmed - https://cirrus-ci.com/build/5768962257190912:
Running with hw.ncpu=8

If there is some sort of hanging test issue I could try wrapping it in
timeout and outputting ps and other info upon failure.

On 2019-01-21 17:30, Ed Maste wrote:
> On Mon, 21 Jan 2019 at 10:16, Ed Maste <emaste@freebsd.org> wrote:
>>
>> To confirm, I have another build running now with
>> echo "Running with hw.ncpu=$(sysctl -n hw.ncpu)"
>> added.
> 
> Confirmed - https://cirrus-ci.com/build/5768962257190912:
> Running with hw.ncpu=8
> 
> If there is some sort of hanging test issue I could try wrapping it in
> timeout and outputting ps and other info upon failure.

Ok, I did some more tests today. First two runs were simply killed:

 https://cirrus-ci.com/build/5478092878381056
 https://cirrus-ci.com/build/5754149284085760

Then I tried to decrease the amount of resources to 4 CPUs and 8G of
RAM, but that timed out:

 https://cirrus-ci.com/build/6003268728651776

Then I finally increased the CPUs back to 8 again, but stick with 8G of
RAM, and that indeed finished in time successfully:

 https://cirrus-ci.com/build/6218565876187136

So yes, looks like 8 CPUs should work indeed, but I think you should
decrease the amount of memory of the VM, to make sure that it does not
get killed so easily. 8 GB of RAM should also be enough to compile QEMU,
as far as I can tell.

 Thomas


PS: I also removed the V=1 in my tests since otherwise the log was way
to verbose for my taste ... but that's likely really just a matter of taste.

On Tue, 22 Jan 2019 at 10:11, Thomas Huth <thuth@redhat.com> wrote:
> PS: I also removed the V=1 in my tests since otherwise the log was way
> to verbose for my taste ... but that's likely really just a matter of taste.

I tend to run the 'make' step without V, and the 'make check' step
with V=1 -- the compile part is fine at lower verbosity because
the compiler will always emit a useful error message if something
fails, but our test harness and tests are very bad at providing
information about why something failed and so you need all
the clues you can get when you're looking at the logfile for a
failed build.

thanks
-- PMM

On Tue, 22 Jan 2019 at 04:40, Thomas Huth <thuth@redhat.com> wrote:
>
> Then I finally increased the CPUs back to 8 again, but stick with 8G of
> RAM, and that indeed finished in time successfully:
>
>  https://cirrus-ci.com/build/6218565876187136
>
> So yes, looks like 8 CPUs should work indeed, but I think you should
> decrease the amount of memory of the VM, to make sure that it does not
> get killed so easily. 8 GB of RAM should also be enough to compile QEMU,
> as far as I can tell.

Ok. I think Cirrus-CI might be having some growing pains.

I can submit a v4 patch with 8G for the VM and V=1 only on the tests,
then after it gets merged keep an eye on results for a while before we
consider enabling build notifications etc.

On 2019-01-22 14:42, Ed Maste wrote:
> On Tue, 22 Jan 2019 at 04:40, Thomas Huth <thuth@redhat.com> wrote:
>>
>> Then I finally increased the CPUs back to 8 again, but stick with 8G of
>> RAM, and that indeed finished in time successfully:
>>
>>  https://cirrus-ci.com/build/6218565876187136
>>
>> So yes, looks like 8 CPUs should work indeed, but I think you should
>> decrease the amount of memory of the VM, to make sure that it does not
>> get killed so easily. 8 GB of RAM should also be enough to compile QEMU,
>> as far as I can tell.
> 
> Ok. I think Cirrus-CI might be having some growing pains.
> 
> I can submit a v4 patch with 8G for the VM and V=1 only on the tests,
> then after it gets merged keep an eye on results for a while before we
> consider enabling build notifications etc.

Sounds like a plan!

 Thanks,
  Thomas