-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backport 2.7: Rationalize Travis builds #3248
Backport 2.7: Rationalize Travis builds #3248
Conversation
Signed-off-by: Gilles Peskine <[email protected]>
Signed-off-by: Gilles Peskine <[email protected]>
Almost everything the selftest program does is in the test suites. But just in case run the selftest program itself once in the full configuration, and once in the default configuration with ASan, in addition to running it out of box. Signed-off-by: Gilles Peskine <[email protected]>
Make it possible to use a compiler that isn't in $PATH, or that's installed with a different name, or even a compiler for a different target such as arm-linux-gnueabi. Signed-off-by: Gilles Peskine <[email protected]>
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 <[email protected]>
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 <[email protected]>
Only this job uses doxygen and graphviz. Signed-off-by: Gilles Peskine <[email protected]>
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 <[email protected]>
Different releases have different sets of sanity checks. Keep the list in one place, namely all.sh. Signed-off-by: Gilles Peskine <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Signed-off-by: Gilles Peskine <[email protected]>
Keep it simple and mostly non-parametrizable for now. A path to Visual Studio 2017 is hard-coded. Signed-off-by: Gilles Peskine <[email protected]>
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 <[email protected]>
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 <[email protected]>
fc0d2a5
to
d43a24b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I consider it as a fair backport as well. What about to add in the description that one patch of #2821 has been dropped? |
Sorry, I don't understand. Which description? Which patch? |
Which description: the description of the PR at the top of the page. Not sure this is the right name for it but I cannot find a better one: #3248 (comment). |
Why would the history in the 2.7 branch mention something that isn't relevant to the 2.7 branch? We don't normally do that and I don't see a good reason to start doing so. |
It's just that in #3248 (comment) you describe what has been dropped from #3218 thus I was thinking why not doing it for #2821 as well. Anyway, this is just a suggestion, I am fine if you feel that it is not worth mentioning what has been dropped (because not relevant to 2.7) from #2821 in that description. |
Ah, ok. I added “the applicable part of” in the PR description. Given the nature of that PR, I think that's enough detail. |
ok, fine by me, thanks. |
Make the running time more even. Signed-off-by: Gilles Peskine <[email protected]>
This is supposed to be for GCC (or a compiler with a compatible command line interface) targeting arm-none-eabi, so name it accordingly. Signed-off-by: Gilles Peskine <[email protected]>
Backport this component that was added to development after 2.7.0. It's easier to keep the 2.7 branch closer to the other maintained branches. Signed-off-by: Gilles Peskine <[email protected]>
Otherwise the bignum assembly code is not used. Signed-off-by: Gilles Peskine <[email protected]>
It's pretty fast and adds a little variety. Signed-off-by: Gilles Peskine <[email protected]>
Just show the code size in the logs, for human consumption. Signed-off-by: Gilles Peskine <[email protected]>
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 <[email protected]>
b1b732a
to
7ccd025
Compare
I force-pushed a change in the commit "Travis: rebalance the Linux builds" because in this branch, it accidentally removed the call to |
Mostly straightforward backport of #3218. Differences:
psa_constant_names
in 2.7, and so no need for Python on Windows.all.sh
,build_arm_none_eabi_gcc_arm5vte
didn't exist in 2.7, so I added it.Like in the 2.16 backport (#3247), first backport (the applicable part of) #2821 because it's easier to keep all LTS branches in synch.