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

105 lines
2.7 KiB
YAML
Raw Normal View History

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
sudo: required
language: c
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
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:'-less jobs appear with their env, e.g.: PLATFORM=sue
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='sue'
- <<: *build-platform
env: PLATFORM='jsl'
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'
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
- name: "./scripts/build-tools.sh"
before_install: *docker-pull-sof
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: ./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
- name: "./scripts/host-build-all.sh"
before_install: *docker-pull-sof
CI: travis: add host build host build is missing during previous scripts refine. Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
2020-02-27 17:45:23 +08:00
script: ./scripts/docker-run.sh ./scripts/host-build-all.sh -l
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:
CI: travis: disable agent for QEMU test QEMU boot test will random fail with agent. Disable it to make sure QEMU boot test will not fail. Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
2019-10-25 16:57:19 +08:00
- sed -i $(($(grep "config HAVE_AGENT" -n src/platform/Kconfig | cut -f1 -d:)+2))"s/default y/default n/" src/platform/Kconfig
.travis.yml: Fix incorrect usage of -j option xtensa-build-all.sh expects number of cores to be used when -j option is specified. By default, it uses all the cores available which is what we want, hence, omitting the option altogether. Signed-off-by: Shreeya Patel <shreeya.patel23498@gmail.com>
2020-04-04 18:01:29 +08:00
- ./scripts/docker-run.sh ./scripts/xtensa-build-all.sh -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
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
- 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:
- ./scripts/docker-run.sh ./scripts/build-tools.sh -t &> /dev/null
- ./scripts/docker-run.sh ./scripts/host-build-all.sh
- ./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).
- mkdir -p doxybuild && pushd doxybuild && cmake -GNinja -S ../doc && ninja -v doc
- 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