| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Problem: No tests for the termdebug plugin
Solution: Add some simple tests for the termdebug plugin
closes: vim/vim#12927
https://github.com/vim/vim/commit/58f39d89a8adff51ab04893d1fd28e3767979f9f
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
|
| |
|
|
| |
It is no longer needed now that luarocks isn't used.
|
| |
|
|
|
|
|
| |
- adjust reviewers
- add workflow as cache key
- install attr only when tesitng
- fix s390x workflow by checking out the merge PR instead of master
|
| | |
|
| |
|
|
|
| |
- add reviewers
- correct cache key
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: No support for writing extended attributes
Solution: Add extended attribute support for linux
It's been a long standing issue, that if you write a file with extended
attributes and backupcopy is set to no, the file will loose the extended
attributes.
So this patch adds support for retrieving the extended attributes and
copying it to the new file. It currently only works on linux, mainly
because I don't know the different APIs for other systems (BSD, MacOSX and
Solaris). On linux, this should be supported since Kernel 2.4 or
something, so this should be pretty safe to use now.
Enable the extended attribute support with normal builds.
I also added it explicitly to the :version output as well as make it
able to check using `:echo has("xattr")`, to have users easily check
that this is available.
In contrast to the similar support for SELINUX and SMACK support (which
also internally uses extended attributes), I have made this a FEAT_XATTR
define, instead of the similar HAVE_XATTR.
Add a test and change CI to include relevant packages so that CI can
test that extended attributes are correctly written.
closes: vim/vim#306
closes: vim/vim#13203
https://github.com/vim/vim/commit/e085dfda5d8dde064b0332464040959479696d1c
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
| |
This will fix the failing release job.
Ubuntu 18.04 is incompatible with checkout action version 4, which
requires glibc 2.28+. This will bump the minimum glibc version required
to use the release versions to 2.31. People requring the older releases
can find them at https://github.com/neovim/neovim-releases.
|
| |
|
|
| |
GitHub paginates responses with many results, which needs to be taken
into account as the number of events in an issue can be large.
|
| | |
|
| |
|
|
| |
This will allow us to use it in containers as well as specify whether we
want to install test dependencies.
|
| |
|
|
| |
The stale action has a bug where it won't close an issue/PR if it has
comments after the stale label.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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`.
|
| |
|
| |
Adding the same team multiple times will fail the review job.
|
| |
|
|
|
|
| |
This catches downstream consumers of neovim off guard when using neovim in an
esoteric environment not tested in our own CI.
Closes https://github.com/neovim/neovim/issues/22932
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
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
|
| |
|
| |
Anyone can review a refactor depending on what's being refactored.
|
| |
|
|
|
| |
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.
|
| |
|
| |
Also update the reviewer list.
|
| |
|
|
|
|
|
|
|
|
| |
ci: remove "needs:response" label if author responds
The default behavior of the stale action is to indiscriminately remove
the `needs:response` label for any activity whatsoever, from anyone. The
other option is to turn it off completely, meaning the maintainers needs
to manually remove the label themselves when the author responds for an
issue to not close automatically. Neither of these behaviors are useful
to us.
|
| |
|
|
|
|
|
|
| |
Using team reviewers when possible reduces the churn on the git history
as we'll be able to add or remove reviewers without needing to change
the workflow files.
This requires using Github fine-grained personal access tokens with Pull
Requests set to "Read and write" and Members to "Read-only".
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
