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.
- Removed NSIS installer.
- Prevents undefined behaviour when two installations are performed to the same directory (NSIS + MSI).
- Reduced cost of maintaining two installers that do the same thing.
- Chose Wix MSI due to its better integration with Windows.
- Added Wix patch file to add neovim binaries to the system path during installation.
- Replaced neovim installer icons with better looking versions.
- Renamed neovim installer icons from logo.ico -> neovim.ico for all
icons to better reflect contents.
1. Add new pattern `runtime/doc/**`. This is a common case were the
contributor modifies only the help file but the doc gen would discard
their changes.
2. Add to the output what the changes after running doc gen would be.
[skip ci]
Repurpose the api-docs workflow to also run in all PR's but work only as
a check, if the changes in the PR introduce doc changes that are not
committed fail.
[skip ci]
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.
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.
This reverts commit 559aa4179c.
I mistakenly believed both ways of writing were equivalent; this is
untrue. Setting continue-on-error to true will make the job pass, but
an error annotation will still be created which is misleading since it's
not actually an error.
GH workflows aren't allowed to trigger other GH workflows. Since
commitlint is a required check now, we need something manual to happen
for it to run on vim-patch/api-doc PRs.
Creating these PRs as drafts and then marking them as "ready to review"
when we want to merge them will provide the manual trigger to run
commitlint.
[skip ci]
Co-authored-by: Sean Dewar <seandewar@users.noreply.github.com>
Co-authored-by: Gregory Anders <greg@gpanders.com>
Co-authored-by: Sebastian Volland <seb@baunz.net>
Co-authored-by: Lewis Russell <lewis6991@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Even though the releaes itself gets deleted, if the tag is not, then
creating a new release just re-uses the same tag, even though we're
using “--target <sha>”.
[skip ci]
Now that we have various GH actions creating branches in the main repo,
using the generic '**' pattern for the CI workflow is just wasting CI
time and leading to more queued jobs.
[skip ci]
