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>
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>
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>
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>
See https://github.com/thesofproject/sof/issues/2752
host-testbench.sh exits with success 0 when tests fail. Random, recent, all
green example in PR #2751:
https://travis-ci.org/github/thesofproject/sof/jobs/672996210 is green but:
eqiir test failed!
I didn't even have to spend time to search for this example, I only
looked at the most recent PR.
Ignoring failures is the very worst type of validation issue because it
makes everyone think everything is OK when it's not. Hides regressions.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
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>
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>
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>
Marc Herbert