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.
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.
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.
This lint job will ensure that the C codebase is properly formatted at
all times. This helps eliminate most of clint.py.
To save CI time, it's faster to manually compile uncrustify and cache
the binary instead of using homebrew (the apt-get package is too old).
previous: https://github.com/neovim/neovim/pull/14123
CI tests were disabled on drafts #18566 to manage the
large number of incoming jobs. While this did help, it had the drawback
of making the purpose of the ready-for-review a bit fuzzier. It went
from a clear "my PR is ready" signal to maintainers to somewhere between
"my PR is ready but I need the tests to confirm" to "please don't merge
yet, I just need to see the test results". Worse is that the specific
case of wanting to see the test results but not wanting it merged is
that this needs to be actively conveyed to the maintainers with a [DNM]
or a comment to not merge the PR yet. All of this causes weird
workarounds and noises which I believe isn't necessary.
The reason why I don't think this workaround is needed anymore is that
our CI now aborts a job if a new job from the same pull requests is
created, which makes the "10 simultaneous jobs per PR" situations that
triggered this not possible.
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.
“make clint-full” bypasses the normal mechanisms used to communicate
build flags in the CI jobs, so explicitly build nvim before running the
lint jobs.
