[Mesa-dev] Running the CI pipeline on personal Mesa branches

[Eric Anholt]

On Fri, Dec 6, 2019 at 3:56 PM Rob Clark <robdclark at gmail.com> wrote:
>
> On Fri, Dec 6, 2019 at 3:46 PM Bas Nieuwenhuizen
> <bas at basnieuwenhuizen.nl> wrote:
> >
> > On Fri, Dec 6, 2019 at 10:49 AM Michel Dänzer <michel at daenzer.net> wrote:
> > >
> > >
> > > I just merged
> > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2794 , which
> > > affects people who want to run the CI pipeline on personal Mesa branches:
> > >
> > > Pushing changes to a personal branch now always creates a pipeline, but
> > > none of the jobs in it run by default. (There are no longer any special
> > > branch names affecting this, because creating MRs from such special
> > > branches resulted in duplicate CI job runs)
> > >
> > > The container stage jobs can be triggered manually from the GitLab UI
> > > (and maybe also via the GitLab API, for people who'd like to automate
> > > this? I haven't looked into that). The build/test stage jobs run
> > > automatically once all their dependencies have passed.
> > >
> > > As an example, in order to run one of the "piglit-*" test jobs, one has
> > > to manually trigger the "x86_build" and "x86_test" jobs.
> > >
> > > The pipelines created for merge requests still run all jobs by default
> > > as before.
> > >
> > >
> > > The main motivation for these changes is to avoid wasting CI runner
> > > resources. In that same spirit, please also cancel any unneeded
> > > build/test jobs. This can be done already before those jobs start
> > > running, e.g. while the container stage jobs run.
> >
> > No complaint about not running the pipelines by default in personal
> > repositories, but expecting people to cancel automatically spawned CI
> > jobs as normal part of their workflow seems incredibly fiddly and
> > fragile to me. Are we *that* constrained?
> >
>
> It would be nice if there was some way to setup some conservative
> filters to exclude groups of tests, ie. if only paths changed were
> under src/freedreno or src/gallium/drivers/freedreno, then no need to
> run panfrost CI, and visa versa.  We probably shouldn't try to fine
> tune that *too* much at this risk of skipping tests that should have
> run, but seems like there should be same safe low hanging fruit to cut
> down on CI runs in common cases.
>
> I guess maybe that only helps if the bottleneck are the hw CI runners,
> which might not be the case.. I'm not sure.

Our bottleneck, every time I go check, is in x86_64 build/test job slots.