- 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.
We must invoke src/nvim/testdir/Makefile directly.
Explained in 3d1084f264:
> Running tests from the top-level Makefile will use the third-party
> dependencies from .deps instead of the ones from the Travis cache.
If we could run `oldtest` with CMake, we would not need to do this. Need
USES_TERMINAL feature (CMake 3.2+) for that.
- Add support for TEST_FILE to the `oldtest` target, for consistency
with the busted/lua tests.
Caveat: with the busted/lua tests TEST_FILE takes a full path, whereas
for `oldtest` it must be "test_foo.res".
- Add support for NVIM_PRG, again so that all test-related targets are
consistent.
- Use consistent name for NVIM_PRG. But still need to support NVIM_PROG
for QuickBuild CI.
Note: The `oldtest` target is driven by the top-level Makefile, because
it requires a TTY. CMake 3.2 added a USES_TERMINAL flag to
add_custom_target(). But we support CMake 2.8...
add_custom_target(oldtest
COMMAND make clean
COMMAND make NVIM_PRG=$<TARGET_FILE:nvim> $ENV{MAKEOVERRIDES}
DEPENDS nvim
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/src/nvim/testdir"
USES_TERMINAL true
)
This was an attempt to enable test/functional/provider/python3_spec.lua
It actually *does* appear to work if we do this:
mingw32-make functionaltest VERBOSE=1 PATH=C:\Python35;C:\Python27;%PATH%
Note that %PATH% *already* has C:\Python35 at its start by then, so
PATH=C:\Python35;C:\Python27;%PATH% is _redundant_.
python3_spec.lua *does* find python3.exe in that case, and succeeds.
But it causes weird failures in unrelated tests:
[----------] Running tests from C:/projects/neovim/test/functional\core\job_partial_spec.lua
[ RUN ] ...rojects/neovim/test/functional\core\job_partial_spec.lua @ 17: jobs with partials works correctly
.\test\functional\helpers.lua:89: Vim(call):E903: Process for command "powershell" could not be spawned
stack traceback:
.\test\functional\helpers.lua:89: in function 'request'
.\test\functional\helpers.lua:147: in function 'nvim_command'
.\test\functional\helpers.lua:344: in function 'source'
...rojects/neovim/test/functional\core\job_partial_spec.lua:18: in function <...rojects/neovim/test/functional\core\job_partial_spec.lua:17>
[ ERROR ] ...rojects/neovim/test/functional\core\job_partial_spec.lua @ 17: jobs with partials works correctly (0.00 ms)
[ RUN ] C:/projects/neovim/test/functional\eval\execute_spec.lua @ 73: execute() does not capture shell-command output
C:/projects/neovim/test/functional\eval\execute_spec.lua:74: Expected objects to be the same.
Passed in:
(string) '
:!echo "foo"
Cannot execute cmd.exe
shell returned -1
'
Expected:
(string) '
:!echo "foo"
'
stack traceback:
C:/projects/neovim/test/functional\eval\execute_spec.lua:74: in function <C:/projects/neovim/test/functional\eval\execute_spec.lua:73>
[ FAILED ] C:/projects/neovim/test/functional\eval\execute_spec.lua @ 73: execute() does not capture shell-command output (15.60 ms)
[ RUN ] C:/projects/neovim/test/functional\ex_cmds\arg_spec.lua @ 11: :argument does not restart :terminal buffer
C:/projects/neovim/test/functional\ex_cmds\arg_spec.lua:18: Expected objects to be the same.
Passed in:
(boolean) false
Expected:
(boolean) true
stack traceback:
C:/projects/neovim/test/functional\ex_cmds\arg_spec.lua:18: in function <C:/projects/neovim/test/functional\ex_cmds\arg_spec.lua:11>
[ FAILED ] C:/projects/neovim/test/functional\ex_cmds\arg_spec.lua @ 11: :argument does not restart :terminal buffer (0.00 ms)
[ RUN ] C:/projects/neovim/test/functional\ex_cmds\edit_spec.lua @ 11: :edit without arguments does not restart :terminal buffer
C:/projects/neovim/test/functional\ex_cmds\edit_spec.lua:16: Expected objects to be the same.
Passed in:
(boolean) false
Expected:
(boolean) true
stack traceback:
C:/projects/neovim/test/functional\ex_cmds\edit_spec.lua:16: in function <C:/projects/neovim/test/functional\ex_cmds\edit_spec.lua:11>
[ FAILED ] C:/projects/neovim/test/functional\ex_cmds\edit_spec.lua @ 11: :edit without arguments does not restart :terminal buffer (15.60 ms)
[ RUN ] ...s/neovim/test/functional\eval\msgpack_functions_spec.lua @ 457: msgpackparse() function msgpackparse(systemlist(...)) does not segfault. #3135
.\test\functional\helpers.lua:89: Failed to evaluate expression
stack traceback:
.\test\functional\helpers.lua:89: in function 'eval'
...s/neovim/test/functional\eval\msgpack_functions_spec.lua:460: in function <...s/neovim/test/functional\eval\msgpack_functions_spec.lua:457>
[ ERROR ] ...s/neovim/test/functional\eval\msgpack_functions_spec.lua @ 457: msgpackparse() function msgpackparse(systemlist(...)) does not segfault. #3135 (15.63 ms)
[ FAILED ] 3 tests, listed below:
[ FAILED ] C:/projects/neovim/test/functional\eval\execute_spec.lua @ 73: execute() does not capture shell-command output
[ FAILED ] C:/projects/neovim/test/functional\ex_cmds\arg_spec.lua @ 11: :argument does not restart :terminal buffer
[ FAILED ] C:/projects/neovim/test/functional\ex_cmds\edit_spec.lua @ 11: :edit without arguments does not restart :terminal buffer
[ ERROR ] 2 errors, listed below:
[ ERROR ] ...rojects/neovim/test/functional\core\job_partial_spec.lua @ 17: jobs with partials works correctly
[ ERROR ] ...s/neovim/test/functional\eval\msgpack_functions_spec.lua @ 457: msgpackparse() function msgpackparse(systemlist(...)) does not segfault. #3135
64 SKIPPED TESTS
3 FAILED TESTS
2 ERRORS
-- Output to stderr:
The system cannot find the path specified.
CMake Error at C:/projects/neovim/cmake/RunTests.cmake:46 (message):
Running functional tests failed with error: 1.
Setup python2/3 and install the Neovim client in Appveyor to
enable the python tests.
- Use the Python installation provided by Appveyor, because dependencies
pyuv, greenlet have issues compiling with MinGW-w64. And this way we
avoid building those too.
- Copy python.exe => python3.exe so that the python provider can find
python3.
Build the default CMake target now that helptag generation is
working again.
For build artifacts create a zip file with an instalation of
Neovim (generated by cpack).
- Build for MinGW x86/x86_64. Move build scripts out of the yml file into
separate batch files.
- The MinGW builds use MSYS to get runtime dependencies, but they do not
link against the POSIX adaptation layer.
- For now only build the nvim.exe binary, but not the helptags.
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.
