[igt-dev] [PATCH i-g-t v2] Add GitLab's CI/CD configuration

[Arkadiusz Hiler]

On Tue, Oct 23, 2018 at 03:30:36PM +0200, Daniel Vetter wrote:
> On Tue, Oct 23, 2018 at 10:32:31AM +0300, Arkadiusz Hiler wrote:
> > On Mon, Oct 22, 2018 at 04:59:36PM +0200, Daniel Vetter wrote:
> > > On Mon, Oct 22, 2018 at 05:38:44PM +0300, Arkadiusz Hiler wrote:
> > > > On Mon, Oct 22, 2018 at 04:25:50PM +0200, Daniel Vetter wrote:
> > > > > On Mon, Oct 22, 2018 at 4:24 PM Arkadiusz Hiler
> > > > > <arkadiusz.hiler at intel.com> wrote:
> > > > > >
> > > > > > On Mon, Oct 22, 2018 at 04:18:56PM +0200, Daniel Vetter wrote:
> > > > > > > On Mon, Oct 22, 2018 at 4:15 PM Arkadiusz Hiler
> > > > > > > <arkadiusz.hiler at intel.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Oct 22, 2018 at 03:09:04PM +0300, Arkadiusz Hiler wrote:
> > > > > > > > > The CI/CD pipeline is configured the following way:
> > > > > > > > >  1. Build docker images and add them to repo's registry (manual step for
> > > > > > > > >     now, automation needs GitLab to be updated).
> > > > > > > > >  2. Build igt with meson on Debian and Fedora.
> > > > > > > > >  3. Run `ninja tests` on Fedora.
> > > > > > > > >  4. Build and publish docs as an artifact, for GitLab Pages.
> > > > > > > > >
> > > > > > > > > v2: Typos and fully-featured meson build.
> > > > > > > > >
> > > > > > > > > Cc: Petri Latvala <petri.latvala at intel.com>
> > > > > > > > > Cc: Daniel Vetter <daniel at ffwll.ch>
> > > > > > > > > Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler at intel.com>
> > > > > > > >
> > > > > > > > Both images are already in our registry.
> > > > > > > >
> > > > > > > > Here you can see the pipline running (on a testing branch):
> > > > > > > > https://gitlab.freedesktop.org/drm/igt-gpu-tools/pipelines/6292
> > > > > > >
> > > > > > > I think the "proper" gitlab way of doing this is not through a
> > > > > > > temporary branch, but through a merge request. Or a personal fork.
> > > > > > > Gives you the exact same amount of gitlab-ci testing as a branch. Just
> > > > > > > an aside, figure we'll start with the process bikeshedding right away
> > > > > > > :-)
> > > > > > > -Daniel
> > > > > >
> > > > > > I was playing with that on my fork, but the issue was that I would have
> > > > > > to change the paths to registry each time I send a patch and push it to
> > > > > > my repo. Too annoying, so I went with a temporary branch.
> > > > > 
> > > > > If you do an MR, does it work better?
> > > > > -Daniel
> > > > 
> > > > They are disabled for IGT, which kind of makes sense, as we do not take
> > > > contributions that way (yet?) - there's no proper CI for MRs.
> > > 
> > > Huh, I guess that was Daniel Stone's doing. I think there's some sense in
> > > having issues disabled, but imo merge requests we can leave enabled. Much,
> > > much easier for test-driving gitlab process issues this way.
> > > 
> > > Ofc anyone who submits as MR only will get redirect to the m-l.
> > > 
> > > Ack if we just enable them again?
> > > -Daniel
> > 
> > I don't like to misguide people. If we don't take contributions this way it
> > just feels wrong to me to have MRs available in the UI.
> > 
> > IMO without the MRs enabled, people are much more likely to read CONTRIBUTING
> > and do the right thing the first time, without unnecessary latency and
> > additional annoyance.
> 
> We can enable MR just for project members. I think that would avoid the
> confusion? I do kinda want to enable them, for experimenting. Ofc can do
> that all with my private fork, but not e.g. for how to integrate
> intel-gfx-CI.
> -Daniel

I am still not convinced that the UI/notification noise is worth the
doubtable benefits. Even if you turn it just for the project members,
the tab in the UI will appear for everyone.

I am fine with turning the MRs on, when we are on the verge of actually
enabling this way of contributing, for the last stage of testing
intel-gfx-ci integration.

Meanwhile, we can be as noisy as we want with our testing on forks.

-- 
Cheers,
Arek