Messages in this thread | | | From | Rob Herring <> | Date | Thu, 4 Oct 2018 14:10:57 -0500 | Subject | Re: [PATCH] Add a skeleton Travis-CI config |
| |
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
| |