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

[Daniel Vetter <daniel.vetter@ffwll.ch>]

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.

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