[libvirt PATCH 2/4] ci: add a job for clang

Andrea Bolognani abologna at redhat.com
Wed Jul 29 09:56:20 UTC 2020


On Wed, 2020-07-29 at 11:02 +0200, Ján Tomko wrote:
> On a Wednesday in 2020, Andrea Bolognani wrote:
> > Also, based on the above, do you think we should have clang builds
> > on more platforms or are two Fedora builds giving us enough coverage?
> 
> The intention was to use different versions of the compiler.

Makes sense when you spell it out :)

> If running it on the oldest still-supported Fedora interferes with
> your passion in purging releases that don't let us drop any code,
> I can replace it with a combination of:
>    rawhide + centos 8 + debian 10
> or
>    rawhide + centos 8 + opensuse 15.1

Either one looks fine. Maybe let's use Debian so that we don't put
all eggs in RPM-based baskets ;)

> > > +++ b/.gitlab-ci.yml
> > > @@ -52,7 +52,7 @@ stages:
> > >    script:
> > >      - mkdir build
> > >      - cd build
> > > -    - ../autogen.sh || (cat config.log && exit 1)
> > > +    - ../autogen.sh CC=$CC || (cat config.log && exit 1)
> > 
> > Have you tried without this hunk?
> 
> No.

Can you please try? :)

> > > +  variables:
> > > +    CC: clang
> > > +    NAME: fedora-31
> > 
> > Bikeshedding: I'd put NAME first.
> 
>    /---\  Speaking of which, do you have a better suggestion for the job
>   |     | name? 'x86-fedora-rawh' is all that fits into the bubble on
>   |  ,  | the pipeline website. Almost as if it was designed for CI,
>   | o-o | not CUT.

Unfortunately he bubble is simply too small to display a reasonable
amount of information, so I don't think we can hope to fit everything
in there. The "jobs" view presents all information, but its structure
is less than ideal.

Recently Cleber created this script for QEMU:

  https://lists.nongnu.org/archive/html/qemu-devel/2020-07/msg03106.html

I wonder if we could build something like that, but which provides
more detailed information, perhaps in a proper TUI... Such a tool
might live under the Bichon umbrella, for example, since there's
clearly some overlap in scope.

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list