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

[Ján Tomko]

On a Wednesday in 2020, Andrea Bolognani wrote:
>On Wed, 2020-07-29 at 01:36 +0200, Ján Tomko wrote:
>> Out of the Linux distros we build on in the CI, clang
>> is only available on Fedora.
>
>Uh? I guess you based this claim on
>
>  https://repology.org/project/clang/versions
>

Yes.

>but the information contained in that page is inaccurate: clang is
>actually also available on
>
>  CentOS 7        3.4.2 (via EPEL)
>  CentOS 8        9.0.1
>  Debian 10       7.0.1
>  Debian sid      10.0.1
>  openSUSE 15.1   7.0.1
>  Ubuntu 18.04    10.0.0
>  Ubuntu 20.04    10.0.0
>
>Some of those versions might be too old to be useful, but claiming
>that clang is only available in Fedora is simply inaccurate.
>
>> Add a job to Fedora 31 and Rawhide, to have coverage
>> for clang on Linux as well.
>
>I get Rawhide, but why Fedora 31 instead of 32? The former is going
>to be EOL in a few months.
>

Any Fedora release is, by definition, going to be EOL in a few months.

>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.

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

(And thanks for pointing that out, my Gentoo box still defaults to
clang7)

>> Includes a refresh of the Dockerfiles to commit TBD:
>> https://gitlab.com/libvirt/libvirt-ci/-/merge_requests/38
>
>I would prefer the Dockerfile update to be its own commit.
>

Yes.

>> +++ 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.

>$CC is already defined in the
>container's environment and I would expect autogen.sh/configure to
>pick the value up, so I *think* it should work even without passing
>it explicitly...
>
>> +x64-fedora-31-clang:
>> +  <<: *native_build_job_definition
>> +  needs: ["x64-fedora-31-container"]
>
>We haven't introduced this pattern yet, so please stick with the
>current approach for the moment and then switch these jobs over along
>with all the other ones in the follow-up commit.
>
>> +  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.

Jano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200729/ccd12c83/attachment-0001.sig>