On Fri, Dec 6, 2019 at 3:56 PM Rob Clark <robdcl...@gmail.com> wrote: > > On Fri, Dec 6, 2019 at 3:46 PM Bas Nieuwenhuizen > <b...@basnieuwenhuizen.nl> wrote: > > > > On Fri, Dec 6, 2019 at 10:49 AM Michel Dänzer <mic...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev