- 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.
Travis is phasing out its support for containers, so we remove the `sudo:
false`, which will be a no-op soon.
Reference: https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration
Changes for Linux:
- Xenial comes with libtool installed already. It only provides "libtoolize",
though. For "libtool" we need to install libtool-bin.
homebrew or Travis changed something, now `pip3` isn't in $PATH.
`ls /usr/local/opt/python/libexec/bin` confirmed this, no matter what
brew reinstall/relink/upgrade are used.
Bumping the macOS image to 10.12 or 10.13 makes the problem go away.
==> Processing gcc49 formula rename to gcc@4.9
==> Unlinking gcc49
==> Moving gcc49 versions to /usr/local/Cellar/gcc@4.9
==> Relinking gcc@4.9
Warning: gcc@4.9 is outdated!
To avoid broken installations, as soon as possible please run:
brew upgrade
Or, if you're OK with a less reliable fix:
brew upgrade gcc@4.9
python info:
Python 2.7.12
Python 2.7.12
ci/before_install.sh: line 18: python3: command not found
pip 8.1.2 from /usr/local/lib/python2.7/site-packages (python 2.7)
pip 8.1.2 from /usr/local/lib/python2.7/site-packages (python 2.7)
ci/before_install.sh: line 21: pip3: command not found
pyenv versions:
* system (set by /Users/travis/.pyenv/version)
Upgrade Python 3.
To restore the stashed changes to /usr/local/Homebrew run:
'cd /usr/local/Homebrew && git stash pop'
==> Caveats
Python has been installed as
/usr/local/bin/python3
Unversioned symlinks `python`, `python-config`, `pip` etc. pointing to
`python3`, `python3-config`, `pip3` etc., respectively, have been installed into
/usr/local/opt/python/libexec/bin
If you need Homebrew's Python 2.7 run
brew install python@2
Pip, setuptools, and wheel have been installed. To update them run
pip3 install --upgrade pip setuptools wheel
You can install Python packages with
pip3 install <package>
They will install into the site-package directory
/usr/local/lib/python3.7/site-packages
See: https://docs.brew.sh/Homebrew-and-Python
==> Summary
º /usr/local/Cellar/python/3.7.0: 8,864 files, 153.8MB, built in 6 minutes 32 seconds
...
Upgrade Python 3 pip.
ci/before_install.sh: line 30: pip3: command not found
travis_time🔚0d23f522:start=1538818824750644000,finish=1538819451424021000,duration=626673377000
The command "ci/before_install.sh" failed and exited with 127 during .
Your build has been stopped.
/Users/travis/.travis/job_stages: line 373: shell_session_update: command not found
==> Processing gcc49 formula rename to gcc@4.9
==> Unlinking gcc49
==> Moving gcc49 versions to /usr/local/Cellar/gcc@4.9
==> Relinking gcc@4.9
Warning: gcc@4.9 is outdated!
To avoid broken installations, as soon as possible please run:
brew upgrade
Or, if you're OK with a less reliable fix:
brew upgrade gcc@4.9
python info:
Python 2.7.12
Python 2.7.12
ci/before_install.sh: line 18: python3: command not found
pip 8.1.2 from /usr/local/lib/python2.7/site-packages (python 2.7)
pip 8.1.2 from /usr/local/lib/python2.7/site-packages (python 2.7)
ci/before_install.sh: line 21: pip3: command not found
pyenv versions:
* system (set by /Users/travis/.pyenv/version)
Upgrade Python 3.
To restore the stashed changes to /usr/local/Homebrew run:
'cd /usr/local/Homebrew && git stash pop'
==> Caveats
Python has been installed as
/usr/local/bin/python3
Unversioned symlinks `python`, `python-config`, `pip` etc. pointing to
`python3`, `python3-config`, `pip3` etc., respectively, have been installed into
/usr/local/opt/python/libexec/bin
If you need Homebrew's Python 2.7 run
brew install python@2
Pip, setuptools, and wheel have been installed. To update them run
pip3 install --upgrade pip setuptools wheel
You can install Python packages with
pip3 install <package>
They will install into the site-package directory
/usr/local/lib/python3.7/site-packages
See: https://docs.brew.sh/Homebrew-and-Python
==> Summary
º /usr/local/Cellar/python/3.7.0: 8,864 files, 153.8MB, built in 6 minutes 32 seconds
...
Upgrade Python 3 pip.
ci/before_install.sh: line 30: pip3: command not found
travis_time🔚0d23f522:start=1538818824750644000,finish=1538819451424021000,duration=626673377000
The command "ci/before_install.sh" failed and exited with 127 during .
Your build has been stopped.
/Users/travis/.travis/job_stages: line 373: shell_session_update: command not found
"Always use `find_package` with `REQUIRED`."
- We make an exception for LuaJit (not REQUIRED): the `nvim-test` target
is included only if we can find LuaJit.
This is partially a cargo-cult (reference below), but it uncovered at
least one problem: `find_package(LibIntl REQUIRED)` fails on my vanilla
ubuntu 16.04 system.
ref: https://schneide.blog/2017/11/06/4-tips-for-better-cmake/
> optional dependencies is nice, but skipping on REQUIRED is not the way
> you want to do it. In the worst case, some of your features will just
> not work if those packages are not found, with no explanation
> whatsoever. Instead, use explicit feature-toggles (e.g. using option())
> that either skip the find_package call or use it with REQUIRED, so the
> user will know that another lib is needed for this feature.
macOS travis builds recently started failing (travis caches were cleared
recently, maybe related). python2 is reasonably covered by linux CI. Not
going to waste time on it for macOS CI.
==> Installing python@2
==> Downloading https://homebrew.bintray.com/bottles/python@2-2.7.14_3.el_capita
==> Pouring python@2-2.7.14_3.el_capitan.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/2to3-2
Target /usr/local/bin/2to3-2
is a symlink belonging to python. You can unlink it:
brew unlink python
To force the link and overwrite all conflicting files:
brew link --overwrite python@2
To list all files that would be deleted:
brew link --overwrite --dry-run python@2
Possible conflicting files are:
/usr/local/bin/2to3-2 -> /usr/local/Cellar/python/2.7.12_1/bin/2to3-2
/usr/local/bin/2to3-2.7 -> /usr/local/Cellar/python/2.7.12_1/bin/2to3-2.7
/usr/local/bin/idle -> /usr/local/Cellar/python/2.7.12_1/bin/idle
...
Homebrew changed a few formulae to meet their standards. "python3" was renamed
to "python", and "python2" to "python@2".
As for why, read this announcement: https://brew.sh/2018/01/19/homebrew-1.5.0
Since we install Python 3 via homebrew anyway, we now do the same for Python 2
as well. We do that because the system Python 2 of macOS comes without pip
installed and this way seems cleaner than doing "sudo easy_install pip".
The Python 2 formula is keg-only now, so it doesn't interfere with the system
Python 2. Therefore we have to add its executables to $PATH ourselves.
Workaround for this fun new issue:
==27404==LeakSanitizer has encountered a fatal error.
==27404==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==27404==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
Failed: E /build|logs :: Runtime errors detected.
https://github.com/travis-ci/travis-ci/issues/9033https://github.com/google/sanitizers/issues/764
Separating the non-flaky builds (asan, normal builds, lint) into
separate stages simply slowed down overall CI turnaround. Since none of
the builds rely on the output of others, reducing the stages increases
the opportunities for parallel builds.
The llvm repos commonly have access issues, so removing them will
improve stability of the Travis builds.
Filtering check_log's output through asan_symbolize also avoids the
version dance every time a new clang version makes its way into Travis.
- Establish ERROR log level as "critical". Such errors are rare and will
be valuable when users encounter unusual circumstances.
- Set -DMIN_LOG_LEVEL=3 for release-type builds
This should better allow distributing the load among PRs, while getting
critical feedback to the submitter sooner.
First stage runs the ASAN/UBSAN/TSAN since any failures in those are
gating issues.
Second stage runs the rest of the normal builds in parallel.
Remaining stages provide lower priority feedback. The lint build runs
fast locally, so it's better to run that locally than wait on CI. The
coverage build is pretty fickle, so it is only run once all other jobs
are green.
