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.
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.
Sanity API checks made by the python-client in the api-python travis target were
converted to lua and will now live in this repository. This will simplify
performing breaking changes to the API as it won't be necessary to send parallel
PRs the python-client.
The 'lupa' python package provides a simple way to seamless integrate lua and
python code.
This commit replaces vroom by a python script that exposes the 'neovim' package
to a lua state, and invokes busted to run functional tests. This is a temporary
solution that will enable writing functional tests using lua/bused while a lua
client library is not available.
The reason for dropping vroom is flexibility: Lua/busted has a nice DSL-style
syntax while also providing the customization power of a full programming
language. Another reason is to use a single framework for unit/functional tests.
Two other changes were performed in this commit:
- Instead of "gcc-unittest/gcc-ia32", the travis builds for gcc are now
identified by "gcc/gcc-32". They will run unit/functional tests for both 64
and 32 bits.
- Old integration tests(in src/nvim/testdir) are now ran by the 'oldtest' target
Add section `before_install` in `.travis.yml` to create test group and
add current user to this group.
It is needed because by default user on Travis-CI belongs only to one
primary group derived from that user. So we have no alternative to
change group of the file.
To simplify modification/inclusion of continuous integration targets, this
removes travis.sh which contains a big if statement in favor of multiple scripts
under the new '.ci' directory.
Run only on push to branch coverity-scan. We can use a cron script to do
this 4 times a week (that's our allowance).
NOTE: possible future improvements are:
1. Fold the build matrix item into another short one so we don't overburden
travis. It's a little less clear but it should be nicer on the
infrastructure.
2. Change the security token, one can do that from the coverity admin page.
3. Don't do the naive `make depend`, but use the prebuilt libraries.
- Add a 'expect' utility script that can run simple API tests using clients
developed for any platform.
- Extend travis build matrix to run API tests using the python client and
valgrind.
This script can be used to write API tests without having to manage nvim's
lifetime:
- It starts a single nvim instance listening on a known socket
- Invokes the test runner, which should connect to NEOVIM_LISTEN_ADDRESS
- The nvim instance started by the script provides a `BeforeEachTest` function,
which should be called before each test to reset nvim to a clean state.
- It takes care of shutting down nvim once the tests are finished.
As explained
[here](https://github.com/neovim/neovim/pull/737#issuecomment-43941520), it's
not possible to fully reset nvim to it's initial state, but the `BeforeEachTest`
function should be enough for most test cases. Tests requiring a fully clean
nvim instance should take care of starting/stopping nvim.
- Build targeting 32-bit with travis
- Code in `before_install`/`after_success` was moved to travis.sh since it
provides greater flexibility for detecting the build matrix environment. This
improves the build speed since we now install only what's necessary.
- Now clint has a dedicated travis worker
- Valgrind configuration removed
- Fix errors reported by the undefined behavior sanitizer
- Travis will now run two build steps:
- A normal build of a shared library for unit testing(in parallel with gcc)
- A clang build with some sanitizers enabled for integration testing.
After these changes travis will run much faster, while providing valgrind-like
error detection.
