From: "Marek Olšák" <maraeo@gmail.com>
To: Nicolas Dufresne <nicolas@ndufresne.ca>
Cc: "Erik Faye-Lund" <erik.faye-lund@collabora.com>,
"Timur Kristóf" <timur.kristof@gmail.com>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
"X.Org development" <xorg-devel@lists.x.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
wayland <wayland-devel@lists.freedesktop.org>,
"X.Org Foundation Board" <board@foundation.x.org>,
"Xorg Members List" <members@x.org>,
"amd-gfx list" <amd-gfx@lists.freedesktop.org>,
"Jason Ekstrand" <jason@jlekstrand.net>,
"Mesa Dev" <mesa-dev@lists.freedesktop.org>,
"Discussion of the development of and with GStreamer"
<gstreamer-devel@lists.freedesktop.org>
Subject: Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
Date: Sun, 1 Mar 2020 00:46:00 -0500 [thread overview]
Message-ID: <CAAxE2A5zSy7Rh6xyPW8NCqj3q0_8F7yw8tAXx=_z8+mJ-u2uWw@mail.gmail.com> (raw)
In-Reply-To: <5551426acf99f73d3ce8234c14c176c1c7a1fe44.camel@ndufresne.ca>
[-- Attachment #1.1: Type: text/plain, Size: 3411 bytes --]
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:
> > > > > 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-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
>
[-- Attachment #1.2: Type: text/html, Size: 4787 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-03-01 5:46 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-27 21:27 gitlab.fd.o financial situation and impact on services Daniel Vetter
2020-02-27 23:45 ` Matt Turner
2020-02-28 7:59 ` Daniel Stone
2020-02-28 10:09 ` Jan Engelhardt
2020-02-28 11:11 ` Daniel Stone
2020-02-28 21:20 ` Matt Turner
2020-02-28 0:21 ` Luc Verhaegen
2020-02-28 0:33 ` Carsten Haitzler
2020-02-28 1:00 ` [Mesa-dev] " Tom Stellard
2020-02-28 1:08 ` Tom Stellard
2020-02-28 3:37 ` [Intel-gfx] " Dave Airlie
2020-02-28 7:44 ` Daniel Vetter
2020-02-28 8:17 ` Daniel Stone
2020-02-28 8:48 ` Dave Airlie
2020-02-28 9:26 ` Daniel Stone
2020-02-28 19:34 ` [Mesa-dev] " Eric Anholt
2020-02-28 20:30 ` Dave Airlie
2020-02-28 21:22 ` Daniel Vetter
2020-02-28 21:37 ` Nuritzi Sanchez
2020-04-04 13:55 ` Andreas Bergmeier
2020-04-05 14:07 ` Nicolas Dufresne
2020-02-28 9:28 ` Erik Faye-Lund
2020-02-28 9:40 ` Lionel Landwerlin
2020-02-28 10:06 ` Erik Faye-Lund
2020-02-28 10:43 ` Daniel Stone
2020-02-28 11:02 ` Erik Faye-Lund
2020-02-28 11:46 ` Michel Dänzer
2020-02-28 13:08 ` Lionel Landwerlin
2020-02-29 18:14 ` Timur Kristóf
2020-02-29 19:46 ` Nicolas Dufresne
2020-02-29 20:28 ` Timur Kristóf
2020-02-29 21:54 ` Jason Ekstrand
2020-02-29 22:20 ` Nicolas Dufresne
2020-03-01 5:46 ` Marek Olšák [this message]
2020-04-03 14:12 ` Michel Dänzer
2020-04-04 15:11 ` Rob Clark
2020-04-04 17:47 ` Nicolas Dufresne
2020-04-04 18:16 ` Rob Clark
2020-04-04 18:41 ` Rob Clark
2020-04-04 18:47 ` Rob Clark
2020-04-04 23:39 ` Peter Hutterer
2020-04-04 23:32 ` Peter Hutterer
2020-04-06 15:42 ` Adam Jackson
2020-04-06 16:34 ` Rob Clark
2020-04-06 17:04 ` Michel Dänzer
2020-04-06 18:00 ` Rob Clark
2020-03-01 14:14 ` [Mesa-dev] [Intel-gfx] " Michel Dänzer
2020-03-01 14:27 ` Nicolas Dufresne
2020-03-01 19:51 ` Jacob Lifshay
2020-03-01 20:18 ` [Intel-gfx] [Mesa-dev] " Jason Ekstrand
2020-03-01 20:30 ` Bridgman, John
2020-03-01 20:49 ` Nicolas Dufresne
2020-03-02 4:53 ` Jason Ekstrand
2020-02-28 9:47 ` [Mesa-dev] [Intel-gfx] " Daniel Vetter
2020-02-28 10:10 ` Erik Faye-Lund
2020-02-28 10:27 ` Lucas Stach
2020-02-28 11:43 ` Michel Dänzer
2020-02-28 17:00 ` [Intel-gfx] [Mesa-dev] " Rob Clark
2020-02-29 15:58 ` Jason Ekstrand
2020-02-28 18:03 ` [Intel-gfx] " Kristian Høgsberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAxE2A5zSy7Rh6xyPW8NCqj3q0_8F7yw8tAXx=_z8+mJ-u2uWw@mail.gmail.com' \
--to=maraeo@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=board@foundation.x.org \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=erik.faye-lund@collabora.com \
--cc=gstreamer-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jason@jlekstrand.net \
--cc=members@x.org \
--cc=mesa-dev@lists.freedesktop.org \
--cc=nicolas@ndufresne.ca \
--cc=timur.kristof@gmail.com \
--cc=wayland-devel@lists.freedesktop.org \
--cc=xorg-devel@lists.x.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).