| Commit message (Collapse) | Author | Age |
| |
|
|
|
| |
Having a workflow that only builds neovim without running all of the
tests is a cheap way to test the build still works without burning too
much CI time.
|
| |
|
| |
15 minutes is too short for TSAN.
|
| |
|
|
|
|
|
|
| |
ci: add GCC release testing
We currently have no release testing, so it's good to check for any
unwanted behavior on release builds as well. Prefer GCC over clang, as
GCC release builds seem to create more warnings on release compared to
debug.
|
| |
|
|
|
| |
Detect if on CI by checking that the CI environment variable is set to "true".
This is a common pattern among CI providers, including github actions and
cirrus.
|
| |
|
|
| |
Bash has better error handling than cmake, and seem overall slightly
more suited to scripting than cmake.
|
| |
|
| |
It's easier if the os-specific installations are done by the script itself
|
| |
|
|
| |
Scripts that define the build itself shouldn't be external as they lead
to hard to find bugs.
|
| |
|
|
| |
Having as few indirections as possible makes it easier to understand the
code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Abstracting the build commands to a separate script makes it more
difficult to reason about it and more error-prone.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
More specifically, move the job testing the oldest supported cmake into
its own job. This opens the way for other jobs to use powerful and
advanced cmake features such as choosing which files to use with the -S
flag.
Removed testing from this job as this probably won't reveal anything
that other jobs already doesn't already show, since the only difference
is the cmake version.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
| |
The CI somtimes freezes on a specific test, wasting 45 minutes for the
entire job. Adding a timeout of 15 minutes to functionaltest and 5
minutes to unittests will mitigate the problem.
|
| |
|
|
|
|
| |
Clang-tidy already does what check-single-includes does automatically on
top of its regular linting. It is also generator independent, so it
doesn't take an eternity to run on slower generators such as Visual
Studio.
|
| |
|
|
| |
Having a clear separation between when we manipulate variables and when
we export them to GITHUB_ENV makes it less error-prone.
|
| |
|
|
|
|
|
| |
Use the bundled libvterm dependency as the external package is outdated,
with the hopes of being able to use the external package once its
version meets our required version.
Co-authored-by: Christian Clason <c.clason@uni-graz.at>
|
| |
|
|
|
|
|
|
| |
This will ensure warnings are treated as errors when using MSVC.
Also fix const correctness warnings. The warnings in mbyte.c are false
positives that triggers this warning on MSVC v19.32 and lower, which our
CI still use. The (void *) casts can be removed once the CI MSVC version
has been upgraded to v19.33 or higher.
|
| |
|
|
|
| |
Running "make lintlua" will run both stylua and luacheck if both exist.
But this is not necessary as we already lint with stylua with the
stylua-action, so we only need to lint with luacheck on our own.
|
| | |
|
| |
|
|
| |
With TUI as an external process oldtests no longer involve threads, so
TSAN isn't useful. Meanwhile functionaltests may involve threads.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Nvim has Lua but the "nvim" CLI can't easily be used to execute Lua
scripts, especially scripts that take arguments or produce output.
Solution:
- support "nvim -l [args...]" for running scripts. closes #15749
- exit without +q
- remove lua2dox_filter
- remove Doxyfile. This wasn't used anyway, because the doxygen config
is inlined in gen_vimdoc.py (`Doxyfile` variable).
- use "nvim -l" in docs-gen CI job
Examples:
$ nvim -l scripts/lua2dox.lua --help
Lua2DoX (0.2 20130128)
...
$ echo "print(vim.inspect(_G.arg))" | nvim -l - --arg1 --arg2
$ echo 'print(vim.inspect(vim.api.nvim_buf_get_text(1,0,0,-1,-1,{})))' | nvim +"put ='text'" -l -
TODO?
-e executes Lua code
-l loads a module
-i enters REPL _after running the other arguments_.
|
| | |
|
| | |
|
| |
|
|
| |
The advantages of using an action is that it reduces boilerplate and
repetition from the main ci.yml workflow.
|
| |
|
|
|
|
| |
Ref https://github.com/actions/runner-images/issues/6586
Some runners are using new images, while some others are using old
image. This is the only way I can find that makes it work on both.
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's currently difficult to pinpoint the cause of a failure since all
tests are run even if the build steps fail. But since the build failed
the test will almost always fail as well as it's dependent on a
successful build, leading to many steps being marked as a failure even
though the real problem was the build step. Even worse, the default
behavior of GitHub Actions is to only automatically show the last failed
step, which is misleading if the build process fails since it'll show
the logs of the failing test step.
An easy solution would be to abort all subsequent steps if any steps
fail. This isn't optimal however, as we want all lint and test failures
to show on a single run instead of prematurely aborting on a single test
step.
We can solve both problems by dividing each job into two phases: the
build/installation phase and the test/lint phase, with a checkmark step
in between. The strategy is simple: if any step before the checkmark
step fails (the build phase), then abort all following steps. If any
step after the checkmark fails (the test phase), then show that test as
failed but continue running all tests.
|
| |
|
|
| |
This will silence the warning about needing to pin the version in the
Summary Page.
|
| |
|
|
| |
This will save around a minute of CI time for each run. Also clean up
build.ps1 by removing unnecessary code.
|
| |
|
|
|
|
| |
Default is currently clang 14. GHA images are updated at least once per year, so
we don't need to manually install a newer clang version.
Also remove step for installing clang-13 since it's not needed anymore.
|
| |
|
|
|
|
| |
This includes both the `lintpy` make target and for CI. We're actively
trying to reduce our python usage, so this only seems to give warnings
for unimportant things such as exceeding the line after deleting python
code.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Skipping the CI on documentation-only changes is no longer appropriate
as we now rely on CI to test parts of documentation, e.g.
test/functional/lua/help_spec.lua.
Ignore changes in contrib/ as it's for non-essential user contributions
that we don't need to test.
|
| |
|
|
| |
Changing the action version to v1 allows us to automatically get patch
updates as it points to the latest stable version.
|
| |
|
|
| |
All steps in lint now do now require a Neovim build.
|
| | |
|
| |
|
|
|
|
|
| |
lintcfull == lintc + uncrustify
We are already running uncrustify separately so can just run lintc
instead.
|
| | |
|
| | |
|
| |
|
|
| |
It was never in action since migrating from travis to github actions.
|
| |
|
|
| |
The differences in MacOS releases are smaller since they're now upgraded
yearly, meaning the need to test each version is reduced.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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'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.
|
| | |
|