It's not needed anymore as it does the exact same thing as
functionaltest. The functionaltest target will test the lua type neovim
was built with, which can be toggled with the PREFER_LUA option.
Uncrustify is sensitive to version changes, which causes friction for
contributors that doesn't have that exact version. It's also simpler to
download and install the correct version than to have bespoke version
checking.
This will allow contributors to test changes in their own fork when
pushing without needing to make a pull request. This can be useful when
wanting to test out an idea before initiating a review process.
Make the following assumptions when defining concurrency:
- Pull request will work the same.
- Pushes to the neovim repo will work the same: each unique commit will
trigger a test run that won't cancel each other.
- Pushes to forks will cancel older CI runs on the same branch, similar
to how pull requests work.
This will create duplicate CI runs when doing a pull request, one in the
neovim repo for the pull request event and one in the fork for the push
event. This is an acceptable trade as the runs in the fork doesn't count
towards the CI limit of neovim. Contributors are also free to disable
these actions in their own fork if they wish.
This will prevent situations where the linting works on CI but not
locally, at the cost of increased CI time.
Also manually ignore `runtime/vim/lua/re.lua`, as the .styluaignore
isn't respected when specifying a file instead of a directory.
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.
`cmake --preset ci`
is equivalent to
`cmake -B build -G Ninja -D CI_BUILD=ON`
Also remove build presets as they're not very useful without workflow
presets, which are only available in schema versions 6 and above.
The shipped versions of xdiff already does everything diff does, so this
duplication of tools isn't necessary. Furthermore, this setup is more
consistent overall, as the 'diffopt=external' option should be for
external programs rather than programs we bundle neovim with.
Install diffutils for oldtests in CI to avoid needing to modify tests.
Team reviewers is a nice feature that comes with a severe drawback: it
makes testing the workflows incredibly difficult as they won't work
without a similar token by the tester.
Currently, the release build picks up headers in
`/Library/Frameworks/Mono.framework/Headers`. You can verify this by
downloading the latest nightly build and checking the output of `nvim
--version`.
These headers are likely to be from a different version of `libintl` than the
one we link to. Let's avoid usage of them by setting `CMAKE_FIND_FRAMEWORK` to
`NEVER`.
Having multiple release artifacts per platform is a maintenance burden.
Furthermore, it is a maintenance burden that doesn't directly improve
the Nvim editor itself. The releases are meant to be a quick way for
users to try out and use neovim on their platform and was never intended
to be a buffet of releases for every conceivable setup.
Users are encouraged to the following replacements:
- Github action `action-setup-vim` to have neovim installed on their
PATH for their CI jobs. See https://github.com/rhysd/action-setup-vim.
- Use the appimage, either as is or by extracting it
- To use as is, run `chmod u+x nvim.appimage && ./nvim.appimage`
- If your system does not have FUSE you can extract the appimage with
`./nvim.appimage --appimage-extract && ./squashfs-root/usr/bin/nvim`
- Build it manually. See https://github.com/neovim/neovim/wiki/Building-Neovim.
Work on https://github.com/neovim/neovim/issues/22684
The labeler adds "lua" label to too many files. When there is already
a "treesitter" or "lsp" label, a "lua" label isn't useful. Instead it's
better to add the label manually to PRs for general Lua support.
