Varnish code coverage results online

Dridi Boukelmoune dridi at
Fri Jan 6 13:47:46 CET 2017

On Fri, Jan 6, 2017 at 12:36 PM, Poul-Henning Kamp <phk at> wrote:
> --------
> In message <CABoVN9BUXbWO3mN34HXDzN_PdL9v757N=PQN309ab++KNHJLvg at>, Dridi Boukelmoune
> writes:
>>On Fri, Jan 6, 2017 at 12:05 PM, Poul-Henning Kamp <phk at> wrote:
>>> If you feel like running a Linux (or other) client, let me know and
>>> we can get it set up, I think my current plan is to run this only
>>> once per night.
>>If we come up with something, Travis CI could do that for us for each
>>push (so some work needs to be done to match the nightly scheduling).
> Doing it on each push would be silly.

We may be able to run the last build "with coverage enabled" using
some API. I don't know, I'd need to look at the docs, but this way it
could be done from the Varnish infra.

> In particular because it takes one and a half error to run "make
> check" with gcov:  Gcov isn't parallel-safe, so all the tests has
> to run serially, and the implementation sucks, so it takes forever
> to update the .g??? files.

I thought gcov'ed binaries could run concurrently if the underlying
file-system allowed it. I never had any issue with gcov and parallel
builds and regardless, if varnishtest spawns a varnishd, won't they
compete on coverage collection for libvarnish for instance?

> I'll look at it, I hadn't considered multiplatform when I did this.
> The simplest is probably to (ab)use vtest to do this.

I don't know about simplest, running nightly builds from a script that
runs pseudo-continuously doesn't sound straightforward.


More information about the varnish-dev mailing list