[Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
Rob Clark
robdclark at gmail.com
Sat Apr 4 15:11:23 UTC 2020
On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer <michel at daenzer.net> wrote:
>
> On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > pre-merge CI.
>
> Thanks for the suggestion! I implemented something like this for Mesa:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
>
I wouldn't mind manually triggering pipelines, but unless there is
some trick I'm not realizing, it is super cumbersome. Ie. you have to
click first the container jobs.. then wait.. then the build jobs..
then wait some more.. and then finally the actual runners. That would
be a real step back in terms of usefulness of CI.. one might call it a
regression :-(
Is there a possible middle ground where pre-marge pipelines that touch
a particular driver trigger that driver's CI jobs, but MRs that don't
touch that driver but do touch shared code don't until triggered by
marge? Ie. if I have a MR that only touches nir, it's probably ok to
not run freedreno jobs until marge triggers it. But if I have a MR
that is touching freedreno, I'd really rather not have to wait until
marge triggers the freedreno CI jobs.
Btw, I was under the impression (from periodically skimming the logs
in #freedesktop, so I could well be missing or misunderstanding
something) that caching/etc had been improved and mesa's part of the
egress wasn't the bigger issue at this point?
BR,
-R
More information about the gstreamer-devel
mailing list