Message-ID: <CAKMK7uF74Sw8P0-2V76utPKoxfBk+13_Po+eW_Mgu+RZq9uEvQ@mail.gmail.com>
Date:   Thu, 4 Oct 2018 21:22:59 +0200
From:   Daniel Vetter <daniel.vetter@...ll.ch>
To:     Rob Herring <robh@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] Add a skeleton Travis-CI config

On Thu, Oct 4, 2018 at 9:11 PM Rob Herring <robh@...nel.org> wrote:
>
> On Thu, Oct 4, 2018 at 3:33 AM Daniel Vetter <daniel.vetter@...ll.ch> wrote:
> >
> > On Thu, Oct 4, 2018 at 12:27 AM Rob Herring <robh@...nel.org> wrote:
> > >
> > > It's convenient to use Travis-CI for doing kernel builds. Doing so
> > > requires a github repo, Travis-CI enabled for that repo, and a
> > > .travis.yml file in the repository. This commit addresses the last part.
> > > Each repository branch must have a .travis.yml file in order to run
> > > Travis-CI jobs.
> > >
> > > Obviously, we can't create a single configuration that works for
> > > everyone as every developer will want to run different configs and
> > > build targets. Therefore, this only adds a skeleton .travis.yml file.
> > > With this a user can either set $CONFIG and $TARGET in their Travis-CI
> > > environment or customized builds can be triggered remotely.
> > >
> > > Here's an example of setting up a matrix build of different
> > > architectures:
> > >
> > > body='{
> > >   "request": {
> > >     "branch": "master",
> > >     "config" : {
> > >       "env": {
> > >         "global": "CONFIG=defconfig TARGET=all",
> > >         "matrix": [
> > >           "ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-",
> > >           "ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-",
> > >           "ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-"
> > >         ]
> > >       }
> > >     }
> > >   }
> > > }'
> > >
> > > curl -s -X POST \
> > >    -H "Content-Type: application/json" \
> > >    -H "Accept: application/json" \
> > >    -H "Travis-API-Version: 3" \
> > >    -H "Authorization: token $TOKEN" \
> > >    -d "$body" \
> > >    https://api.travis-ci.org/repo/robherring%2Flinux/requests
> > >
> > > Additionally, it is possible to override 'scripts' or any other part of
> > > the config as well.
> > >
> > > Signed-off-by: Rob Herring <robh@...nel.org>
> > > ---
> > > I'm wondering if there's other interest in this. If so, please chime in.
> > >
> > > Maybe I should be looking at Gitlab CI instead, but Travis I know
> > > already and Gitlab just seems to be the shiniest new thing. In any case,
> > > both could coexist.
> >
> > So I haven't looked in-depth at the travis+github combo, but on gitlab
> > you can set the path for your .gitlab-ci.yaml file per-repo. Which
> > means each maintainer group can have their own thing, without
> > trampling on each another's feet.
>
> Yes, that's a nice feature.
>
> > I guess if gitlab+travis can't do that then a dispatcher like you
> > propose here would be good. Personally I have reservations with gitlab
>
> You mean github here?

Yup.

> > though, since it's proprietary infrastructure not under out control.
> > That's a big reason for why fd.o opted for gitlab, and the handful of
> > graphics projects that tried out a gitlab+travis workflow all plan to
> > move back to gitlab.fd.o. Gitlab definitely works - there's enough
> > projects out there to prove that :-) But in the kernel we've already
> > seen how that can go all wrong with bitkeeper.
>
> The difference here is this is all auxiliary tools on top of the main
> workflow, not a core tool everyone relies on.
>
> It would be nice if there was some standardization of CI config files
> then moving CI providers would be trivial.

Ime moving CI providers is pretty far from trivial. E.g. gitlab uses
docker images for its builders, and it's very much recommended you
build a specific docker images so your builds don't first have to
install a bunch of packages and set up a few things. travis otoh knows
much more about what you need, and does all the build env caching on
the server side automatically. Really not all that easy to flip
between the two.

Plus then all the hand-rolled CI setups running on private maintainer machines.

The other bit is that if your CI isnt' part of your workflow, then it
won't work. The "continuous" part is really the key.

Anyway, definitely don't want to stop this effort, just figured I'll
drop my take on this. I'm pretty sure I'll submit a
drivers/gpu/.gitlab-ci.yaml as soon as we've moved to gitlab.fd.o :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Powered by blists - more mailing lists