On Thu, Oct 4, 2018 at 12:27 AM Rob Herring <r...@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 <r...@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.
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
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.
-Daniel
>
> Rob
>
> .travis.yml | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 .travis.yml
>
> diff --git a/.travis.yml b/.travis.yml
> new file mode 100644
> index 000000000000..ba1e59dd44f6
> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,23 @@
> +language: c
> +
> +sudo: false
> +dist: trusty
> +
> +cache:
> + apt: true
> +
> +env:
> + - CONFIG=allnoconfig TARGET=all
> +
> +addons:
> + apt:
> + packages:
> + - build-essential
> + - bc
> + - gcc-arm-linux-gnueabihf
> + - gcc-aarch64-linux-gnu
> + - gcc-powerpc-linux-gnu
> +
> +script:
> + - make $CONFIG
> + - make $TARGET
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
