linux-kernel - Re: [git pull] drm CI integration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKMK7uFZXqykUOAbdu6+vTdm4UukJVKLcNfZFdtxaLUafvoxJw@mail.gmail.com>
Date:   Tue, 12 Sep 2023 10:16:54 +0200
From:   Daniel Vetter <daniel.vetter@...ll.ch>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Dave Airlie <airlied@...il.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm CI integration

On Sun, 10 Sept 2023 at 21:05, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Wed, 30 Aug 2023 at 18:00, Dave Airlie <airlied@...il.com> wrote:
> >
> > This is a PR to add drm-ci support files to the upstream tree.
>
> So I finally had no other pull requests pending, and spent some time
> looking at this, and I see nothing offensive.
>
> I did wonder how this then expands to having more than one subsystem
> using this (and mixing them possibly on the same CI system), but
> that's more about my ignorance about how the gitlab CI works than
> anything else, so that's certainly not a real concern.

I forgot to put this into my write up, but one reason I think gitlab
CI is a notch better than all the others is that it at least tries to
have an answer here:
- each gitlab repo has its own configuration for where to find the CI
files (also out-of-tree if you go really wild for hw testing maybe)
- you can include gitlab CI files

Which together means you can share common stuff like compile testing
or qemu based testing while easily having specific jobs per
driver/subsystem/whatever that do hw testing. So if media also gains
fd.o gitlab support the media stuff could be in drivers/media/ci (and
at that point we probably want scripts/ci for common stuff).

> The other side of that "I do wonder" coin is for when others want to
> use the same tests but using some other CI infrastructure, whether
> it's some AWS or google cloud thing, or github or whatever.

gitlab has a standalone runner, so at least for the sw-only stuff if
you have some other Ci (like distros that want to test everything)
they should be able to reuse the fd.o specific stuff fairly verbatim,
or at least with some minimal adjustements in upstream. So building a
CI-of-CIs should be doable. Worst case one level below reusing the
docker images should be doable in practically anything that can run a
vm.

> Anyway, considering that both of my idle curiosity reactions were
> about "if this is successful", I think me having those questions only
> means that I should pull this, rather than questioning the pull
> itself.
>
> If it works out so well that others want to actually do this and
> integrate our other selftests in similar manners, I think that would
> be lovely.
>
> And if - as you say - this is a failure and the whole thing gets
> deleted a year from now as "this didn't go anywhere", it doesn't look
> like it should cause a ton of problems either.
>
> Anyway, it's in my tree now, let's see where it goes.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch