This thing still fails with "need manual review" error.
Try devmode (again)--since we got approved once, maybe it works now?
ref 49849745f1
ref d9ab83d057
ref #11482
This swaps it with "gcc-32bit".
It is better to have the "coverage" job run than "gcc-32bit" in case of
flaky build failures - especially on master, since otherwise no base
coverage is available for future PRs.
- use CACHE_NVIM_DEPS_DIR
- do not cache pip
This is handled through http caches in general/better, and it is not
used much anyway.
- do not cache DEPS_DOWNLOAD_DIR
Built deps are cached, downloads are not needed then.
- display ccache stats before clearing
- do not cache ccache stats
- improve output of `du` (do not list pages of output for "/home/travis/.cache/go-build")
The "osx" jobs are the slowest ones, and often still flaky.
I think it is good enough to have a single one there (since they only use
different compilers).
This should improve build times in general (with multiple running
builds, since we're using less jobs per build), and also make flaky job
failures less likely.
While it still might be flaky sometimes, it is far better than the
osx jobs in general, and due to it being allowed to fail, we are not
getting aware of more recent (flaky) issues due to building tags during
make-install, which might indicate a more generic problem.
* ci: Travis: use gcc-9 in gcov job
* ci: Travis: use CCACHE_CPP2=1
This is required to avoid warnings with newer gcc/clang.
Follow-up to: https://github.com/neovim/neovim/pull/10533
- Move __gcov_flush to process_spawn, for more reliable coverage
tracking of subprocesses
- Travis: use GCOV_ERROR_FILE
- codecov: use "-X fix" to skip "fixing" uploaded coverage data; it
should be handled by codecov's backend instead.
- AppVeyor: no $PATH mangling, which breaks with the improved coverage tracking
due to missing .dll in PATH.
This is meant to not fall back to using the cache for the "master"
target branch, for release pull requests (targeting not "master").
(Travis builds the cache key based on all (explicit) job environment
variables)
This moves the 4 fastest jobs there, effectively resulting in a separate
OSX stage then.
Travis typically runs 4/5 jobs in parallel, so this avoids a) running the
slower OSX builds if there are problems already, and b) will start other
builds already earlier (e.g. after the lint job finished).
Install gperf using package manager instead of building it from source.
When building/installing gperf from source, its install step requires
`texi2pdf` which randomly goes missing on Travis:
cd doc; /usr/bin/make install
make[1]: Entering directory '/home/travis/nvim-deps/build/src/gperf/doc'
cd . && rm -f gperf.aux gperf.toc gperf.cp gperf.fn gperf.ky gperf.pg gperf.tp gperf.vr gperf.log gperf.cps
cd . && texi2pdf gperf.texi
/bin/sh: 1: texi2pdf: not found
It's nice to test the "bundled" deps on Travis, but that gets enough
exercise on Windows and macOS, which are the platforms that actually
need "bundled" gperf.
