[Mesa-dev] Enabling freedreno CI in Mesa MRs

[Rob Clark]

On Fri, Sep 6, 2019 at 3:09 PM Eric Anholt <eric at anholt.net> wrote:
>
> Rob Clark <robdclark at gmail.com> writes:
>
> > On Wed, Sep 4, 2019 at 1:42 PM Eric Anholt <eric at anholt.net> wrote:
> >>
> >> If you haven't seen this MR:
> >>
> >> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1632
> >>
> >> I feel ready to enable CI of freedreno on Mesa MRs.  There are some docs
> >> here:
> >>
> >> https://gitlab.freedesktop.org/mesa/mesa/blob/e81a2d3b40240651f506a2a5afeb989792b3dc0e/.gitlab-ci/README.md
> >>
> >> Once we merge this, this will greatly increase Mesa's pre-merge CI
> >> coverage on MRs by getting us up to GLES3.1 going through the CTS.  Once
> >> krh is ready to put up an in-progress MR of tess, we can override the
> >> GLES3.1 run to force-enable 3.2 with the remaining tess issues as
> >> expected fails, and get a whole lot more API coverage.
> >>
> >> As far as stability of this CI, I've been through I think an order of
> >> magnitude more runs of the CI than are visible from that MR, and I'm
> >> pretty sure we've got a stable set of tests now -- I'm currently working
> >> on fixing the flappy tests so we can drop the a630-specific skip list.
> >> The lab has also been up for long enough that I'm convinced the HW is
> >> stable enough to subject you all to it.
> >
> > I won't claim to be an unbiased observer, but I'm pretty excited about
> > this.  This has been in the works for a while, and I think it is to
> > the point where we aren't going to get much more useful testing of our
> > gitlab runners with it living off on a branch, so at some point you
> > just have to throw the switch.
> >
> > I'd propose, that unless there are any objections, we land this Monday
> > morning (PST) on master, to ensure a relatively short turn-around just
> > in case something went badly.
> >
> > (I can be online(ish) over the weekend if we want to throw the switch
> > sooner.. but I might be AFK here and there to get groceries and things
> > like that.  So response time might be a bit longer than on a week
> > day.)
>
> I'm going to be gone on my yearly bike trip until Tuesday, so I propose
> delaying until then so I can be more responsive :)

Works for me

BR,
-R