For Mesa, we could run CI only when Marge pushes, so that it's a strictly pre-merge CI.
Marek On Sat., Feb. 29, 2020, 17:20 Nicolas Dufresne, <nico...@ndufresne.ca> wrote: > Le samedi 29 février 2020 à 15:54 -0600, Jason Ekstrand a écrit : > > On Sat, Feb 29, 2020 at 3:47 PM Timur Kristóf <timur.kris...@gmail.com> > wrote: > > > On Sat, 2020-02-29 at 14:46 -0500, Nicolas Dufresne wrote: > > > > > 1. I think we should completely disable running the CI on MRs which > > > > > are > > > > > marked WIP. Speaking from personal experience, I usually make a lot > > > > > of > > > > > changes to my MRs before they are merged, so it is a waste of CI > > > > > resources. > > > > > > > > In the mean time, you can help by taking the habit to use: > > > > > > > > git push -o ci.skip > > > > > > Thanks for the advice, I wasn't aware such an option exists. Does this > > > also work on the mesa gitlab or is this a GStreamer only thing? > > > > Mesa is already set up so that it only runs on MRs and branches named > > ci-* (or maybe it's ci/*; I can't remember). > > > > > How hard would it be to make this the default? > > > > I strongly suggest looking at how Mesa does it and doing that in > > GStreamer if you can. It seems to work pretty well in Mesa. > > You are right, they added CI_MERGE_REQUEST_SOURCE_BRANCH_NAME in 11.6 > (we started our CI a while ago). But there is even better now, ou can > do: > > only: > refs: > - merge_requests > > Thanks for the hint, I'll suggest that. I've lookup some of the backend > of mesa, I think it's really nice, though there is a lot of concept > that won't work in a multi-repo CI. Again, I need to refresh on what > was moved from the enterprise to the community version in this regard, > > > > > --Jason > > > > > > > > That's a much more difficult goal then it looks like. Let each > > > > projects > > > > manage their CI graph and content, as each case is unique. Running > > > > more > > > > tests, or building more code isn't the main issue as the CPU time is > > > > mostly sponsored. The data transfers between the cloud of gitlab and > > > > the runners (which are external), along to sending OS image to Lava > > > > labs is what is likely the most expensive. > > > > > > > > As it was already mention in the thread, what we are missing now, and > > > > being worked on, is per group/project statistics that give us the > > > > hotspot so we can better target the optimization work. > > > > > > Yes, would be nice to know what the hotspot is, indeed. > > > > > > As far as I understand, the problem is not CI itself, but the bandwidth > > > needed by the build artifacts, right? Would it be possible to not host > > > the build artifacts on the gitlab, but rather only the place where the > > > build actually happened? Or at least, only transfer the build artifacts > > > on-demand? > > > > > > I'm not exactly familiar with how the system works, so sorry if this is > > > a silly question. > > > > > > _______________________________________________ > > > mesa-dev mailing list > > > mesa-...@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > _______________________________________________ > mesa-dev mailing list > mesa-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
