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, nicolas@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.kristof@gmail.com
wrote:
On Sat, 2020-02-29 at 14:46 -0500, Nicolas Dufresne wrote:
- 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-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev