[PATCH] Add a skeleton Travis-CI config

[PATCH] Add a skeleton Travis-CI config

[Rob Herring]

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.

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

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

[Daniel Vetter]

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

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

[Rob Herring]

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

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

[Daniel Vetter]

On Thu, Oct 4, 2018 at 9:11 PM Rob Herring <robh@kernel.org> wrote:
>
> 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?

Yup.

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

Ime moving CI providers is pretty far from trivial. E.g. gitlab uses
docker images for its builders, and it's very much recommended you
build a specific docker images so your builds don't first have to
install a bunch of packages and set up a few things. travis otoh knows
much more about what you need, and does all the build env caching on
the server side automatically. Really not all that easy to flip
between the two.

Plus then all the hand-rolled CI setups running on private maintainer machines.

The other bit is that if your CI isnt' part of your workflow, then it
won't work. The "continuous" part is really the key.

Anyway, definitely don't want to stop this effort, just figured I'll
drop my take on this. I'm pretty sure I'll submit a
drivers/gpu/.gitlab-ci.yaml as soon as we've moved to gitlab.fd.o :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch