Don't use an all.sh component because there isn't one that does what we
want (modern Clang with ASan, and test everything).
* We need to set CC explicitly or tweak PATH, because clang in $PATH on
Travis focal instances is Clang 7 which is too old (we want Clang 10).
* Travis lacks the array of versions of openssl and gnutls that we normally
use for testing, so we need to exclude some tests (or build our
own multiple versions of openssl and gnutls).
The SSL test exclusions are ad hoc and based on what currently works.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Although Coverity have now changed their URL to point at the new
project, they did not change the project name, it would seem.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Travis stopped being able to push builds to coverity due to the token
apparently being no longer valid. Rotating the token to see if that
fixes things.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Our shebangs use `python3`, which is the desired name on Linux (where
`python` is still Python 2). But on Windows, Choco's Python only provides a
`python3.exe` executable. Our build scripts deal with this, but we need to
cope when invoking a Python script from Travis itself.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This way we get our chosen Python version everywhere, and pip is available.
Travis doesn't support the python job type on Windows, however, so keep
installing Python manually there.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Was getting errors like:
In file included from /usr/include/limits.h:25:0,
from /usr/lib/gcc-cross/arm-linux-gnueabi/5/include-fixed/limits.h:168,
from /usr/lib/gcc-cross/arm-linux-gnueabi/5/include-fixed/syslimits.h:7,
from /usr/lib/gcc-cross/arm-linux-gnueabi/5/include-fixed/limits.h:34,
from ../include/mbedtls/check_config.h:30,
from ../include/mbedtls/build_info.h:81,
from common.h:26,
from asn1write.c:20:
/usr/include/features.h:367:25: fatal error: sys/cdefs.h: No such file or directory
There are two packages to choose from: armhf or armel. Since the comment
in all.sh says we're trying to be close to Debian's "armel"
architecture, choose that, and fix a comment that was mentioning
gnueabihf for no apparent reason.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
On Linux, all.sh takes care of it. On Windows, run
make_generated_files.bat.
Perl is now required on Windows.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
`tests/scripts/all.sh check_python_files` now runs mypy (in addition
to pylint) if it's available. So install mypy.
Install mypy 0.780, which is the earliest version that works on our
code at this time.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
With the increase in depends testing for PSA changes introduced
here the Travis builds are now taking too long. The check for
compilation guards will only be run on Jenkins now. See this comment
for further details.
https://github.com/ARMmbed/mbedtls/pull/3585#discussion_r485189748
Signed-off-by: John Durkop <john.durkop@fermatsoftware.com>
The Cortex-A build is similar to Debian armel. The Cortex-M0+ is a
handy point of comparison for code size. Put that one last so that
it's easy to find in the log.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Travis Windows machines currently don't have Python 3 preinstalled.
We need it to run scripts/generate_psa_constants.py which is needed
to build mbedTLS.sln.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Only the Visual Studio 2017 toolset is currently preinstalled on Travis.
Use this, instead of our solution's default which is VS 2010.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Travis now offers a Windows environment. Do a build with Visual
Studio. This brings diversity into the Travis CI which otherwise only
uses GCC and Clang.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Just do the default build with Clang and run the unit tests. The
objective is to have one build on a Unix-like platform other than
Linux.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add a baremetal build to Travis, to catch inadvertent dependencies on
platform functions.
The exact choice of target platform doesn't matter for this purpose.
Pick one that's present in all.sh, that uses a compiler that's
available in the Travis build environment (Ubuntu 16.04), and that
happens to be close to the Debian "armel" distribution.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Call all.sh to run all the available test_depends_* components. This
adds a run of depends-hashes.pl and depends-pkgalgs.pl.
Keep invoking test-ref-configs.pl rather than via all.sh so that it
doesn't run with ASan. This saves some time and ASan there doesn't
turn up much more than in the full config.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Some jobs don't actually test against GnuTLS, but all.sh checks its
presence in all test jobs, so it needs to be installed regardless.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
For the one long job with ASan, use the full configuration.
We get more coverage this way, at the cost of a slightly longer
runtime which we can afford since the "enumerated configurations" job
is slower.
Add a default-configuration build to the "basic checks" job. This job
is fairly quick (no ASan, no SSL testing).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This way anything we change in all.sh, such as adding tests for
programs/*/*, will be reflected here.
The build now uses GCC instead of Clang, which doesn't make much
difference in practice. The build now enables ASan and UBSan.
The tests now run compat.sh and ssl-opt.sh fully.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Different releases have different sets of sanity checks. Keep the list
in one place, namely all.sh.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Declare an explicit Python version. Pick 3.5 which is the default
version on Ubuntu 16.04. This is necessary on Travis to have a working
pip for Python 3.
Install Pylint 2.4.4. There's nothing special about this version, it's
just the latest version.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Split the build between:
* Basic checks
* A build in the default configuration with extensive tests
* Builds in other configurations with less testing
The intent is to have one shorter job with basic tests, and two longer
jobs that take roughly the same amount of time (split as evenly as
possible while keeping an easy-to-understand separation).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In practice, we hardly ever get different outcomes, so there is no
gain in running tests with different compilers.
Experimentally, with the builds and tests we currently do and with the
compiler versions on a Travis Ubuntu 16.04, gcc jobs are significantly
faster than clang jobs (13 min vs 24 min). So use gcc.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
