Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20181003222715.28667-1-robh@kernel.org> <CAKMK7uHYnOVJBn57M0yxgXWAxrkg79+rz0zX+7XRHt8KwgvOuw@mail.gmail.com>
In-Reply-To: <CAKMK7uHYnOVJBn57M0yxgXWAxrkg79+rz0zX+7XRHt8KwgvOuw@mail.gmail.com>
From:   Rob Herring <robh@kernel.org>
Date:   Thu, 4 Oct 2018 14:10:57 -0500
Message-ID: <CAL_Jsq+DpM5Cea-y08MXDP-AKUE07KpwUoCbiRgH_iSkZU6cSA@mail.gmail.com>
Subject: Re: [PATCH] Add a skeleton Travis-CI config
To:     Daniel Vetter <daniel.vetter@ffwll.ch>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Oct 4, 2018 at 3:33 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> On Thu, Oct 4, 2018 at 12:27 AM Rob Herring <robh@kernel.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@kernel.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?

> 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.

Rob