| Commit message (Collapse) | Author | Age |
... | |
|
|
|
| |
If the configuration fails then lints shouldn't be run, as most lint
steps depends on a successful configuration.
|
|
|
|
|
|
| |
Building with Release and RelWithDebInfo build types only on build
system changes is too optimistic, as shown by
https://github.com/neovim/neovim/pull/22436 and
659234c95a23307486a4b7496f3f4391a4bdbe58.
|
|
|
|
| |
close #21063
|
| |
|
|
|
|
| |
Notable changes are performance increases for fetching repositories and
simpler workflow file.
|
|
|
| |
This will ensure we don't accidentally have outdated actions.
|
| |
|
|
|
| |
Co-authored-by: Ben Morgan <cassava@iexu.de>
|
|
|
|
|
|
|
| |
Having to specify CI_BUILD for every CI job requires boilerplate. More
importantly, it's easy to forget to enable CI_BUILD, as seen by
8a20f9f98a90a7a43aea08fcde2c40a5356b4f7b. It's simpler to remember to
turn CI_BUILD off when a job errors instead of remembering that every
new job should have CI_BUILD on.
|
|
|
|
|
|
| |
Multi-config generators can be tricky so testing them would be good.
Also test GCC release and MinSizeRel build types as they're prone to
unusual warnings. Remove release testing from test.yml as this is a
sufficient replacement.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
libtool, autoconf, automake and perl are no longer dependencies of
neovim and doesn't need to be installed in CI anymore. The dependencies
and the commit that removed them as dependencies are the following:
libtool: b05100a9eaad5980ea7652137bc4a1c2d15d752f
perl: 20a932cb72cf077d54e3498ef93341ffe3d4cdbb
autoconf+automake: e23c5fda0a3fe385af615372c474d4dad3b74464
|
|
|
| |
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.
|
|
|
|
| |
As the trigger type is no longer pull_request_target there is no longer
any risk of using the lintcommit script directly from the user PR.
|
|
|
| |
Anyone can review a refactor depending on what's being refactored.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
The default output is too verbose and messy for someone not already
familiar with lintcommit, which defeats it purpose.
|
|
|
|
|
|
|
| |
Using the base branch as cache means that pull requests won't be able to
use the cache from the master branch, since the master branch cache
doesn't have a base_ref as it's generated from a push. Removing base_ref
makes the cache key from master and PR branch the same, provided the any
build files don't change.
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
The universal macos release is particularly sensitive to build system
changes. Adding a job that builds a universal binary whenever a cmake
file is changed will help prevent future release breaks.
|
|
|
|
| |
Having a clear separation between when we manipulate variables and when
we export them to GITHUB_ENV makes it less error-prone.
|
|
|
|
| |
This allows us to get rid of the separate "nvim-test" target
|
|
|
|
| |
news.txt is only meant as a reminder, but contributors have no way of
knowing this automatically without such a message.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
The default merge branch is unreliable when trying to determine number
of commits in a PR. Using the HEAD branch of the PR removes this
ambiguity.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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_.
|
|
|
|
|
|
|
|
|
|
| |
Problem:
The "system info" fields in the bug report take up a lot of space at the
top. That hides the most relevant part of the bug report. To read the
actual bug, you always have to scroll down.
Solution:
Move the "system info" fields to the bottom.
|
|
|
|
| |
- Ask for problem/solution format.
- Drop "Vim version" field, it is usually empty and takes up too much space.
|
|
|
| |
Also update the reviewer list.
|