- 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.
Compile `nvim` executable against Lua if PREFER_LUA=ON.
As the testing library `nvim-test` requires LuaJIT, it is
still compiled against LuaJIT. If LuaJIT is not available,
`nvim-test` is not built.
Reasoning:
1. gtest is better then something like utfTerminal, yet it is way too verbose.
2. gtest cannot be configured to show colors always.
3. Actually I am going to add a CMake target which will allow running tests
(especially, functional tests) in parallel, but this is not going to work
well with any of the default output handlers. Build in this case must be more
or less silent, yet debuggable. New handler does not support this in this
commit though.
1. CI_TARGET now determines which run_${CI_TARGET}.sh script to use. Defaults to
`tests`.
2. Build no longer halts on the first failing suit: e.g. if functional tests
failed it will continue with unit tests, etc.
3. All ${MAKE_CMD} occurrences moved to `top_make` function, added `build_make`
as an alias to `make -C build` (`"${MAKE_CMD}" -C "${BUILD_DIR}"`) which is
too verbose.
`suite.sh` was copied from powerline (tests/common.sh file), assumes running
with POSIX shells (and actually uses dash in powerline). Then some convenience
functions were added (run_test and below).
- Do not exclude any directories from `find` search, remove dumps before tests
instead.
- Install `apport` on travis so that linux tests should produce core dumps
(based on information from travis-ci/travis-ci#3754, not sure whether it still
applies).
- Check cores in lua so that one has an idea which test is failing exactly. Do
this only 10% of time on linux because traversing the file system is slow.
Unit tests are still not touched, though it is what `app` argument in
`check_cores` is for.
TODO? consider using `find`, it may be faster. Consider retiring `os.execute`,
dealing with escaping is bad.
This fixes failures with TSAN builds like
FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x55deea465000 < 0x7cf000000000)
FATAL: Make sure to compile with -fPIE and to link with -pie.
Update to a recent, but not bleeding-edge, version of macOS and xcode.
At present, travis defaults to OS X 10.9.5 / Xcode 6.1.
QuickBuild runs macOS 10.10.
- Check if MIN_LOG_LEVEL value is a number 0-3, default to
INFO (1) or ignore it in Release mode
- When TRAVIS_CI_BUILD is ON the default is DEBUG (0)
- Add local.mk.example
Install Python 3.3 from the Deadsnakes PPA. As this doesn't have pip,
install it manually into ~/.local.
~/.local/bin is apparently in Travis's default PATH, meaning "pip"
doesn't refer to Python 2's pip anymore, but to the manually
installed Python 3 version. Updated the scripts to use version-
suffixed executable names (e.g. pip2.7).
Set CC=cc to use system's default compiler when installing Python
modules, as gcc on OS X had a problem with compiling one of the
dependencies of the Neovim Python module.
Instead of just caching the third-party build output, cache the full
build directory. Always run make to ensure that updated dependencies
are downloaded.
This fixes gcov/coveralls warnings like the following:
Segmentation fault (core dumped)
charset.c.gcno:version '501*', prefer '406*'
Out of memory allocating 33061786568 bytes after a total of 2522648 bytes
http://stackoverflow.com/a/14676272/249642
* Split build steps to utilize the Travis build lifecycle.
* Move shell code from `.travis.yml` into Bash files in `.ci/`,
one file for each step of the Travis build lifecycle.
* Use configuration variables in `.travis.yml` to change
build behavior (e.g. build 32-bit with `BUILD_32BIT=ON`).
* Keep all configuration in environment variables in
`.travis.yml`. In scripts, concatenate environment variables
according to configuration to change to different behavior.
* Add GCC 5 builds for Linux.
* Use Travis's caching feature [1] for third-party dependencies
and pip packages.
* Allow failures MSan, as the errors it reports have to be
fixed first.
Valgrind is still disabled, but can be enabled by setting
`env: VALGRIND=ON` for a job in `.travis.yml`.
[1] http://docs.travis-ci.com/user/caching
* Functional tests fail with SIGPIPE: disable them until we
figure out the exact problem.
* MSan reports some warnings: allow failures for the Travis
build to allow fixing them in individual follow-up PRs.
