linux-kernel - Re: [PATCH] Add a skeleton Travis-CI config

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 4 Oct 2018 14:10:57 -0500
From:   Rob Herring <robh@...nel.org>
To:     Daniel Vetter <daniel.vetter@...ll.ch>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] Add a skeleton Travis-CI config

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?

> 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