Something environmental changed in travis so that it started preferring
the ubuntu clang-3.9 version instead of the llvm.org one. This breaks the
sanitiser based builds. This change forces travis to de-prioritise the
ubuntu clang packages.
[extended tests]
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3759)
If it did, it really is something that should be checked in, and should
therefore make a CI build fail.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3686)
One particular build was running out of memory. By swapping to debug mode
we reduce the optimisation level which should reduce the amount of memory
required.
[extended tests]
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3601)
Modify one of the integration builds so that that the
OPENSSL_SMALL_MEMORY option is compiled. There doesn't appear to be an
automatic build with this option set.
I think the options in the modified build are covered elsewhere (without
the small memory) but a new job might still be preferable.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3268)
This gets us a newer Clang, and newer Go.
1.1.0 already runs on Trusty without issues.
To do this, we need to disable afalgeng in the -Werror build.
afalgeng isn't compatible with the -Werror build on
Travis Trusty due to kernel header mismatch.
(See also 97043e46aa)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Since CI is engaged on per merge request basis, it can be wasteful to
run each request through all the tests, especially those resource
consuming. Idea is to mark most of tests as "extended" and provide a
way to opt-in by marking last commit with [extended tests] tag. It's
still not as optimal as one could wish, as decision to skip a test
still requires machine time, and it's taken in configured environment,
i.e. with updates and additional packages installed...
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2292)
Travis OS X utilization and backlog statistics suggest that it became
bottleneck for our integration builds with requests piling up for days
during working days of the week. Suggestion is to remove osx till
capacity is lesser issue.
Reviewed-by: Richard Levitte <levitte@openssl.org>
We should move it back to the BORINGTEST build when we are approaching
interoperability.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2123)
The fuzzers use -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION, and actually
get different results based on that. We should have at least some
targets that actually fully use the fuzz corpora.
Reviewed-by: Rich Salz <rsalz@openssl.org>
GH: #2023
Clang on Linux seems to catch things that we might miss otherwise.
Also, throw in 'no-deprecated' to make sure we test that as well.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1839)
- make 'pip install --user cpp-coveralls' conditional;
- limit no-stdio to single build per operating environment;
- omit enable-asan duplicate;
Reviewed-by: Richard Levitte <levitte@openssl.org>
Run tests with coverage and report to coveralls.io
For simplicity, this currently only adds a single target in a
configuration that attempts to maximize coverage. The true CI coverage
from all the various builds may be a little larger.
The coverage run has the following configuration:
- no-asm: since we can't track asm coverage anyway, might as well measure the
non-asm code coverage.
- Enable various disabled-by-default options:
- rc5
- md2
- ec_nistp_64_gcc_128
- ssl3
- ssl3-method
- weak-ssl-ciphers
Finally, observe that no-pic implies no-shared, and therefore running
both builds in the matrix is redundant.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
The rationale is that installation from a tarball is a common task
that everyone performs. For all other builds, we do specialised
tests, and might as well build them directly in the checkout, which
also gives us fuzz corpora.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
- Use the new enable-ubsan and enable-asan configuration options.
- Separate ubsan and asan runs.
- In addition, run shared ubsan tests to get more coverage.
(Shared asan tests need a bit more thought to get them working.)
Reviewed-by: Rich Salz <rsalz@openssl.org>
