| Message ID | 20181003222715.28667-1-robh@kernel.org |
|---|---|
| State | New |
| Headers | show |
| Series | Add a skeleton Travis-CI config | expand |
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
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
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
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
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 -- 2.17.1