[igt-dev] [PATCH i-g-t] ci: build with Clang

[Arkadiusz Hiler]

On Thu, Apr 25, 2019 at 01:54:45PM +0000, Ser, Simon wrote:
> On Thu, 2019-04-25 at 15:49 +0200, Daniel Vetter wrote:
> > On Thu, Apr 25, 2019 at 01:05:28PM +0300, Jani Nikula wrote:
> > > On Thu, 25 Apr 2019, Daniel Vetter <daniel at ffwll.ch> wrote:
> > > > On Wed, Apr 24, 2019 at 07:15:26PM +0300, Simon Ser wrote:
> > > > > This adds a build step with Clang on Fedora. Hopefully this can help keeping
> > > > > Clang builds healthy.
> > > > > 
> > > > > Signed-off-by: Simon Ser <simon.ser at intel.com>
> > > > > ---
> > > > >  .gitlab-ci.yml | 8 ++++++++
> > > > >  1 file changed, 8 insertions(+)
> > > > > 
> > > > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > > > > index ae8cbb67..e7d31376 100644
> > > > > --- a/.gitlab-ci.yml
> > > > > +++ b/.gitlab-ci.yml
> > > > > @@ -47,6 +47,14 @@ build:tests-fedora-oldest-meson:
> > > > >      - ninja -C build
> > > > >      - ninja -C build igt-gpu-tools-doc
> > > > >  
> > > > > +build:tests-fedora-clang:
> > > > > +  stage: build
> > > > > +  script:
> > > > > +    - dnf install -y clang
> > > > > +    - export CC=clang
> > > > > +    - meson $MESON_OPTIONS build
> > > > > +    - ninja -C build
> > > > 
> > > > Uh why?
> > > > 
> > > > The thing that broken is building on non-x86 hosts, and that's the thing
> > > > gitlab CI caught. I have no idea why this is all about clang (imo it's
> > > > not), and I don't think we should care about clang either.
> > > 
> > > And why shouldn't we care about clang?
> > 
> > What I meant is: We already have gitlab ci targets that caught the recent
> > clang regression (because a lot more broke). No one gave a shit from what
> > I can tell, so I guess I'm questioning the value of more gitlab CI targets
> > in general. We could fix that by going to merge requests and blocking
> > pulls that fail to build I guess.
> > -Daniel
> 
> I guess no one gave a shit because it was still a little bit early in
> the morning. By the time people noticed the Clang patch was already
> submitted. All I want to say is: Petri (and probably other maintainers
> too) does monitor CI build status.
> 
> I strongly agree with you: pre-merge checks would be a lot better.

We will get there one day :-)

gitlab-ci was the easiest way to give people some control on build
testing.

There is an idea to create gfx-ci/igt-tags repo, where each pre-merge
tree would be pushed. That would give us results from the
gitlab-ci. With some plumbing we could push those to patchwork.

I have to ask daniels first whether our omnibus gitlab is able to handle
that though.

-- 
Cheers,
Arek