| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
This partially reverts commit 7d0479c55810af9bf9f115ba69d1419ea81ec41e.
The job has been particularly unstable when used with docker on
cirrus-ci, which is especially bad as it's meant to be a non-flaky and
simple test.
|
|
|
|
|
|
| |
Cirrus ci automatically pushes/caches docker images, which makes
containerization much simpler to handle. Moving this job to cirrus ci
shortens the job by a minute, and reduces github actions CI usage by two
minutes per PR.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having CI scripts that is separate from the build system causes
tremendous amounts of problems, headaches and bugs. Testing the validity
of the scripts locally become near impossible as time goes on as they're
only vetted if it works on whatever CI provider we happened to have at
the time, with their own quirks and behavior.
The extra indirection between "cmake <-> general CI scripts <-> GHA" is
also a frequent source of problems, as the orchestration needs to be
done with environment variables, cmake flags and github actions matrix
strategy. This combination has turned out to be exceptionally fragile.
Examples:
https://github.com/neovim/neovim/commit/15394b6855c3b17be06bf2bfbac7797d9c3ebf1d
https://github.com/neovim/neovim/commit/13aa23b62af4df3e7f10687b76fe8c04efa2a598
https://github.com/neovim/neovim/pull/22072#discussion_r1094390713
A lot of the code was inlined to .github/workflows/ci.yml without
further modifications. While this in itself doesn't integrate with our
build system any more than the current situation, it does
1. remove a level of indirection, and more importantly
2. allow us to slowly start integrating the CI into our build system now
that all the relevant code is in one place.
|
|
|
|
|
|
| |
* ci: show all logs at the end of a run
The current CI won't show the logs on error due to early exit. This will
at least show the logs, although for all tests at once.
|
|
|
| |
There shouldn't be any core dumps before we have started testing.
|
|
|
|
| |
Abstracting the build commands to a separate script makes it more
difficult to reason about it and more error-prone.
|
|
|
| |
This will get rid of the common/ directory.
|
|
|
|
|
| |
I don't think it's possible to meaningfully abstract away caching on
multiple providers, as each provider has different mechanisms
on how they work.
|
|
|
| |
These aren't needed as we don't use codecov anymore.
|
|
|
|
| |
The tests already have a summary at the end, there's no need for an
additional fail summary wrapper.
|
| |
|
|
|
|
| |
Having a clear separation between when we manipulate variables and when
we export them to GITHUB_ENV makes it less error-prone.
|
| |
|
|
|
|
| |
It shouldn't be sneakily run alongside the nvim build. If it's to
be used it should be done in a separate step.
|
| |
|
|
|
|
| |
This allows us to get rid of the separate "nvim-test" target
|
|
|
|
| |
With TUI as an external process oldtests no longer involve threads, so
TSAN isn't useful. Meanwhile functionaltests may involve threads.
|
|
|
| |
Context: https://github.com/neovim/neovim/pull/21166#issuecomment-1377623160
|
|
|
|
| |
Main benefit is that this will return the correct exit code by default,
meaning the lengthy workarounds to properly fail a test aren't needed.
|
| |
|
|
|
|
| |
This will save around a minute of CI time for each run. Also clean up
build.ps1 by removing unnecessary code.
|
| |
|
| |
|
|
|
|
| |
It was never in action since migrating from travis to github actions.
|
|
|
|
| |
Problem: Windows package step failed (silently).
Solution: Make sure to configure cmake before attempting to build the package target.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor `build.ps1` into a more modular design
https://github.com/neovim/neovim/blob/9728f3b558c8cf9bd2bc331de8a5cc80ba0d3797/.github/workflows/ci.yml#L283-L296
- Separate CI steps.
- Remove unneeded code related to setting up CMake.
- Use parallel/incremental builds.
- Fix github's cache.
- Clear the way for the possibility of replacing this file with a cmake-preset:
https://github.com/neovim/neovim/pull/19128
|
|
|
|
|
| |
It only runs run_tests.sh and checks coverage, which can be replaced by
just moving the coverage check to ci/run_tests.sh.
|
|
|
|
|
|
| |
It's a leftover artifact that currently just acts as an unnecessary
intermediary script that calls the Makefile. It can be replaced by just
calling the Makefile directly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Dirs "config", "packaging", and "third-party" are all closely related
but this is not obvious from the layout. This adds friction for new
contributors.
Solution:
- rename config/ to cmake.config/
- rename test/config/ to test/cmakeconfig/ because it is used in Lua
tests: require('test.cmakeconfig.paths').
- rename packaging/ to cmake.packaging/
- rename third-party/ to cmake.deps/ (parallel with .deps/)
|
|
|
|
|
|
|
|
|
| |
* build: move the logic for linters to cmake
Cmake is our source of truth. We should have as much of our build
process there as possible so everyone can make use of it.
* build: remove redundant check for ninja generator
The minimum cmake version as of writing this is 3.10, which has ninja
support.
|
|
|
|
|
|
| |
> DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020
Testing `pynvim` compatibility with python2 should not be done in core,
and there's only a provider_spec for python3 either way.
|
|
|
|
|
| |
The macOS CI jobs fail to properly install the perl provider, making the
entire thing fail.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unnecessary CI builds increase the change of spurious failures, which are costly
noise. Of course, we should fix all legitimate bugs, but we also cannot
micro-manage every platform, so there needs to be a clear motivation for the CI
builds that we maintain.
Reasons against maintaining a mingw CI job:
1. The windows mingw build is slow.
2. Failures:
- https://github.com/neovim/neovim/issues/18494
- https://github.com/neovim/neovim/issues/18495
3. The mingw artifact is 10x bigger than the windows MSVC artifact:
https://github.com/neovim/neovim/issues/10560
4. Our releases publish the MSVC (not mingw) artifact for Windows users:
https://github.com/neovim/neovim/releases
5. Non-MSVCRT has limitations documented by libuv: http://docs.libuv.org/en/v1.x/process.html
> On Windows file descriptors greater than 2 are available to the child process only if the child processes uses the MSVCRT runtime.
Closes https://github.com/neovim/neovim/issues/18551
|
| |
|
|
|
|
| |
Co-authored-by: Jordan Haine <jhaine@securitycompass.com>
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
On GitHub Actions it just repeats the summary that is shown just after.
When run outside of GitHub Actions it erroneously shows the summary of
the previous suites.
|
|
|
|
|
| |
We always know where in the test we are anyway, it's just needless
repetition.
|
| |
|
|
|
|
| |
This reverts commit 07d3fb6e3b5f9f10b24103363ea7203deb336f06.
|
|
|
|
| |
The oltests hang on windows, making all CI runs fail.
|
|\
| |
| | |
ci: remove failing windows CI tests
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
The VS 2019 CMake generator no longer has different generator types for
different architectures. Now, the architecture is specified via CMake's
`-A` switch. However, this requires we also propagate
`${CMAKE_GENERATOR_PLATFORM}` to the bundled deps, so they build for the
same architecture as Nvim.
|
|\ \
| | |
| | | |
ci: improve cpack packaging
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Addresses: #12571
- Added the following installers through CMake files:
- Windows NSIS.
- Windows MSI.
- Windows zip.
- MacOs tarball.
- Linux tarball.
- Linux Deb package.
- Tweaked pipeline CPack commands to build using new CMakeLists.txt configuration file.
- Added icons and relevant packaging files.
- Updated notes.md to reflect new installation instructions.
This isn't meant to be the perfect solution, it's simply a first pass at using a
simple packaging system to build Windows installers. A Debian package has also
been added since it's very easy but other packages have been left out due to
limiting the scope. Hopefully we can build further upon this and improve it
over time with code signing, better icons and more user-friendly installation
graphics and so on.
|
| | | |
|
| |/
|/| |
|