OrgACRN
/
sof
mirror of https://github.com/thesofproject/sof.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
sof/.travis.yml

113 lines
2.9 KiB
YAML
Raw Normal View History

travis: remove deprecated 'sudo: required' As reported by travis lint: [x] [warn] on root: deprecated key: sudo (The key `sudo` has no effect anymore.) Also copy to the top of the file well-tested .travis.yml tips from sof/linux/.travis.yml Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-09-16 03:08:54 +08:00
---
# Suggested tools that can save round-trips to github and a lot of time:
#
# yamllint .travis.yml
# ~/.gem/ruby/2.7.0/bin/travis lint .travis.yml
# yaml merge-expand .travis.yml exp.yml && diff -b -u .travis.yml exp.yml
ci: travis-ci: add initial travis.ci configuration file. This file should install a docker image and build all targets using gcc. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
2018-08-02 07:52:04 +08:00
language: c
travis: upgrade distribution to Ubuntu 20.04 The current default Travis default is 16.04 which is obsolete. From https://github.com/thesofproject/linux/pull/2402 > Everyone uses 20.04, period. SOF CI also uses 20.04. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-09-20 05:20:35 +08:00
# Ubuntu 20.04 LTS
dist: focal
ci: travis-ci: add initial travis.ci configuration file. This file should install a docker image and build all targets using gcc. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
2018-08-02 07:52:04 +08:00
ci: traris: seprate job to show build stage Seprate build scripts to show build stage of each platforms. Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
2018-10-09 15:20:41 +08:00
git:
depth: false
ci: travis-ci: add initial travis.ci configuration file. This file should install a docker image and build all targets using gcc. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
2018-08-02 07:52:04 +08:00
services:
- docker
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
# We don't need the strict sequence of stages; for now we use stages
CI: Travis: reduce the number of stages to two Travis stages are designed not to run after the first that fails. We never used them for that, only for nicer presentation of results. Running all tests independently of each other (e.g.: qemu and doxygen) even when one fails is more important than presentation, so reduce the number of stages to just two: "buildonly" and "tests" Travis job name: doesn't look as good alone as when combined with a stage name but it's enough to identify jobs. Reducing to just one stage is tempting but it would require a lot more naming surgery so let's start with this small diff and two stages for now. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-11 08:44:50 +08:00
# only as presentation labels. Nothing in stage "tests" will run if
# anything in buildonly fails; in the future we may want to get rid of
# stages.
ci: traris: seprate job to show build stage Seprate build scripts to show build stage of each platforms. Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
2018-10-09 15:20:41 +08:00
stages:
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
- buildonly
CI: Travis: reduce the number of stages to two Travis stages are designed not to run after the first that fails. We never used them for that, only for nicer presentation of results. Running all tests independently of each other (e.g.: qemu and doxygen) even when one fails is more important than presentation, so reduce the number of stages to just two: "buildonly" and "tests" Travis job name: doesn't look as good alone as when combined with a stage name but it's enough to identify jobs. Reducing to just one stage is tempting but it would require a lot more naming surgery so let's start with this small diff and two stages for now. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-11 08:44:50 +08:00
- tests
ci: travis-ci: add initial travis.ci configuration file. This file should install a docker image and build all targets using gcc. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
2018-08-02 07:52:04 +08:00
travis: remove sue creek Sue Creek support was never completed, stop building it as it may give a wrong impression. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-09-16 12:12:00 +08:00
# 'name:'-less jobs appear with their env, e.g.: PLATFORM=tgl
ci: traris: seprate job to show build stage Seprate build scripts to show build stage of each platforms. Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
2018-10-09 15:20:41 +08:00
jobs:
include:
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
CI: Travis: reduce the number of stages to two Travis stages are designed not to run after the first that fails. We never used them for that, only for nicer presentation of results. Running all tests independently of each other (e.g.: qemu and doxygen) even when one fails is more important than presentation, so reduce the number of stages to just two: "buildonly" and "tests" Travis job name: doesn't look as good alone as when combined with a stage name but it's enough to identify jobs. Reducing to just one stage is tempting but it would require a lot more naming surgery so let's start with this small diff and two stages for now. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-11 08:44:50 +08:00
# stage buildonly
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
- &build-platform
stage: buildonly
before_install:
&docker-pull-sof
docker pull thesofproject/sof && docker tag thesofproject/sof sof
script:
.travis.yml: build ROM for "buildonly" platforms too No obvious reason not to build ROM for "buildonly" platforms too. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-06-23 14:54:15 +08:00
./scripts/docker-run.sh ./scripts/xtensa-build-all.sh -r $PLATFORM
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
env: PLATFORM='jsl'
.travis.yml: build Sue Creek Sue Creek is the only platform using the ALIGN() macro in assembly. If it had been built in CI then we would have avoided the ALIGN() regression in commit 39266cac81f4 ("core: assure alignment is only done on power of 2 values"). Building Sue Creek is practically free and finds bugs so let's build it. I'm aware Travis isn't the future but it's still running for now and this is a tiny and totally trivial change that took 1/100 of the time spent writing this commit message. It's also a reminder not to forget Sue Creek in whatever will replace Travis. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2021-01-16 09:17:00 +08:00
- <<: *build-platform
env: PLATFORM='sue'
xtensa-build-all.sh: add tgl with xtensa-cnl-elf. No rimage yet. Copy the icl and cnl configurations. This build with the gcc toolchain has NOT been tested on tgl. The purpose is purely to add the gcc build to CI, avoid future gcc bitrot and catch more warnings and bugs. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-06-16 14:14:29 +08:00
- <<: *build-platform
env: PLATFORM='tgl'
travis: add tgl-h build Add tgl-h build check in Travis Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
2020-12-10 13:44:17 +08:00
- <<: *build-platform
env: PLATFORM='tgl-h'
travis: run build-tools.sh with CMAKE_BUILD_TYPE=Release For some reason gcc prints more warnings this way and of course CI is meant to catch warnings as soon as possible. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-09-15 12:28:28 +08:00
- name: "./scripts/build-tools.sh Release"
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
before_install: *docker-pull-sof
travis: run build-tools.sh with CMAKE_BUILD_TYPE=Release For some reason gcc prints more warnings this way and of course CI is meant to catch warnings as soon as possible. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-09-15 12:28:28 +08:00
script: CMAKE_BUILD_TYPE=Release ./scripts/docker-run.sh ./scripts/build-tools.sh
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
CI: Travis: reduce the number of stages to two Travis stages are designed not to run after the first that fails. We never used them for that, only for nicer presentation of results. Running all tests independently of each other (e.g.: qemu and doxygen) even when one fails is more important than presentation, so reduce the number of stages to just two: "buildonly" and "tests" Travis job name: doesn't look as good alone as when combined with a stage name but it's enough to identify jobs. Reducing to just one stage is tempting but it would require a lot more naming surgery so let's start with this small diff and two stages for now. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-11 08:44:50 +08:00
# stage tests
CI: travis: update with matrix to hold more platforms Use matrix to maintain build job for easy extension. Add workaroud to QEMU test to avoid accuracy error may cause false alarm in boot test. Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
2019-10-24 13:35:42 +08:00
- &qemuboottest
CI: Travis: reduce the number of stages to two Travis stages are designed not to run after the first that fails. We never used them for that, only for nicer presentation of results. Running all tests independently of each other (e.g.: qemu and doxygen) even when one fails is more important than presentation, so reduce the number of stages to just two: "buildonly" and "tests" Travis job name: doesn't look as good alone as when combined with a stage name but it's enough to identify jobs. Reducing to just one stage is tempting but it would require a lot more naming surgery so let's start with this small diff and two stages for now. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-11 08:44:50 +08:00
stage: tests
CI: travis: update with matrix to hold more platforms Use matrix to maintain build job for easy extension. Add workaroud to QEMU test to avoid accuracy error may cause false alarm in boot test. Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
2019-10-24 13:35:42 +08:00
script:
.github: replace HAVE_CONFIG KConfig hack with an override Should make git describe --dirty clean. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2021-03-23 09:29:45 +08:00
- echo CONFIG_HAVE_AGENT=n > src/arch/xtensa/configs/override/no-agent.config
- ./scripts/docker-run.sh ./scripts/xtensa-build-all.sh -o no-agent -r $PLATFORM
CI: travis: update with matrix to hold more platforms Use matrix to maintain build job for easy extension. Add workaroud to QEMU test to avoid accuracy error may cause false alarm in boot test. Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
2019-10-24 13:35:42 +08:00
- ./scripts/docker-qemu.sh ../sof.git/scripts/qemu-check.sh $PLATFORM
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
env: PLATFORM='byt cht'
CI: travis: update with matrix to hold more platforms Use matrix to maintain build job for easy extension. Add workaroud to QEMU test to avoid accuracy error may cause false alarm in boot test. Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
2019-10-24 13:35:42 +08:00
before_install:
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
- *docker-pull-sof
travis: fold long lines; fixes the last yamllint warnings yamllint clean. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-09-20 05:29:06 +08:00
- docker pull thesofproject/sofqemu &&
docker tag thesofproject/sofqemu sofqemu
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
CI: travis: update with matrix to hold more platforms Use matrix to maintain build job for easy extension. Add workaroud to QEMU test to avoid accuracy error may cause false alarm in boot test. Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
2019-10-24 13:35:42 +08:00
- <<: *qemuboottest
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
env: PLATFORM='bdw hsw'
CI: travis: Add boot test for i.MX8 imx8 is now supported in qemu up to boot. So, add it to boottest list. Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
2020-02-26 16:17:18 +08:00
- <<: *qemuboottest
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
env: PLATFORM='apl skl kbl'
CI: travis: Add boot test for i.MX8X i.MX8X is now supported in qemu up to boot. So, add it to boottest list. Signed-off-by: Diana Cretu <diana.cretu@nxp.com>
2020-02-27 15:47:39 +08:00
- <<: *qemuboottest
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
env: PLATFORM='cnl icl'
CI: travis: Add boot test for i.MX8M i.MX8M is now supported in qemu up to boot. So, add it to boottest list. Signed-off-by: Diana Cretu <dianacretu2806@gmail.com>
2020-03-20 20:37:02 +08:00
- <<: *qemuboottest
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
env: PLATFORM='imx8 imx8x imx8m'
CI: Travis: reduce the number of stages to two Travis stages are designed not to run after the first that fails. We never used them for that, only for nicer presentation of results. Running all tests independently of each other (e.g.: qemu and doxygen) even when one fails is more important than presentation, so reduce the number of stages to just two: "buildonly" and "tests" Travis job name: doesn't look as good alone as when combined with a stage name but it's enough to identify jobs. Reducing to just one stage is tempting but it would require a lot more naming surgery so let's start with this small diff and two stages for now. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-11 08:44:50 +08:00
- name: testbench
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
before_install: *docker-pull-sof
CI: travis: Add host-testbecnh build test topology. builg host-testbench Test with host-testbench. Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
2020-03-30 16:45:13 +08:00
script:
.travis.yml: switch to newer rebuild-testbench.sh Also stop hiding errors in topologies build. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-08-29 02:23:45 +08:00
# testbench needs some topologies
- ./scripts/docker-run.sh ./scripts/build-tools.sh -t
- ./scripts/docker-run.sh ./scripts/rebuild-testbench.sh
CI: travis: Add host-testbecnh build test topology. builg host-testbench Test with host-testbench. Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
2020-03-30 16:45:13 +08:00
- ./scripts/host-testbench.sh
CI: travis: add doxygen stage Before this new stage, doxygen was run only in a completely different repo (sof-docs). So it was possible to submit totally broken doxygen changes and get no doxygen feedback at all from CI before merge. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 08:02:15 +08:00
CI: Travis: less VM isolation for speed-up. Remove matrix. Looking at any recent Travis build log: 1. more than half the time is spent in the exact same "docker pull" command, 2. The qemuboottest stage rebuilds again the exact same thing than the previous test stage. Fix 1. by re-using the same docker instance for multiple platforms. Fix 2. by dropping from the test stage builds performed again in the qemuboottest stage. Random sample before: Total (VM) time 1 hr 15 min Real time 25 min (depends on current Travis load) After: Total (VM) time 30 min Real time 10 min (depends on current Travis load) The price to pay for this matrix reduction and speed up is coarser reports in case of failure. Considering these tests are the most basic possible one expects them to be rarely ever broken. Remove the top-level matrix expansion as it was becoming impractical for these heterogeneous builds ("PLATFORM=tools"?!). The combination of the matrix and YAML anchors was not very obvious. Use YAML anchors exclusively. Rename default stage "test" to "buildonly" Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 14:19:34 +08:00
CI: Travis: reduce the number of stages to two Travis stages are designed not to run after the first that fails. We never used them for that, only for nicer presentation of results. Running all tests independently of each other (e.g.: qemu and doxygen) even when one fails is more important than presentation, so reduce the number of stages to just two: "buildonly" and "tests" Travis job name: doesn't look as good alone as when combined with a stage name but it's enough to identify jobs. Reducing to just one stage is tempting but it would require a lot more naming surgery so let's start with this small diff and two stages for now. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-11 08:44:50 +08:00
- name: doxygen
CI: travis: add doxygen stage Before this new stage, doxygen was run only in a completely different repo (sof-docs). So it was possible to submit totally broken doxygen changes and get no doxygen feedback at all from CI before merge. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 08:02:15 +08:00
before_install: sudo apt-get -y install ninja-build doxygen graphviz
script:
# Show ALL warnings. Warnings don't cause doxygen to fail (yet).
travis: fold long lines; fixes the last yamllint warnings yamllint clean. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-09-20 05:29:06 +08:00
- mkdir -p doxybuild && pushd doxybuild && cmake -GNinja -S ../doc &&
ninja -v doc
CI: travis: add doxygen stage Before this new stage, doxygen was run only in a completely different repo (sof-docs). So it was possible to submit totally broken doxygen changes and get no doxygen feedback at all from CI before merge. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2020-04-08 08:02:15 +08:00
- popd
# Build again (it's very quick) and report a failure in Travis if
# any issue. This time doxygen stops on the first issue.
- printf 'WARN_AS_ERROR = YES\n' >> doc/sof.doxygen.in
- ninja -C doxybuild -v doc
.travis.yml: add IRC notifications SOF has #sof dedicated channel on irc.freenode.net server. This will enable travis ci to send notifications to the IRC channel each time a build is finished (either successful or not). We will see how this works and refine it later if it is too spammy. Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
2020-06-11 21:05:37 +08:00
notifications:
irc:
channels:
- "chat.freenode.net#sof"
on_success: always
on_failure: always