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.
This was set explicitly to ubuntu.22.04 as ubuntu-latest pointed to
ubuntu.20.04, and we needed 22.04 to have a new enough doxygen version
for this job to work. Now that ubuntu-latest points to 22.04 this
workaround is no longer needed.
asan_symbolize-14 gives a deprecation as it relies on outdated python
features. We can safely stop using asan_symbolize as it's only needed
for special cases such as cross compilation which we don't have to worry
about.
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".
If any commit message in the PR is either of type "feat" or is a
breaking change, then there's a high probability that news.txt should be
updated. Give an error if news.txt hasn't been updated in that case.
This workflow cannot 100% correctly determine if news.txt should be
updated even if the commit messages were exactly correct. The entries in
news.txt is determined by changes between releases, while the commit
messages are based on the master branch. While it is an approximation,
it is still a useful enough one that it's still valuable to have this
job as a reminder even if it gives an error if it shouldn't. In these
cases it is perfectly fine to ignore the failure for this job.
The needs:response label should only be added and removed manually, and
the action's behavior of removing the label on any activity (e.g. title
change, removing reviewers) is unwanted.
Stale strategy is to never automatically stale anything. Only mark stale
issues or PRs if they get the `needs:response` label. In that case close
after 30 days if there hasn't been any activity.
This reverts commit d7e2229b41.
This workflow isn't required to pass to merge a PR any more. Using
pull_request_target to bypass the required check when using [skip ci] is
therefore no longer needed.
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.
Switch back to Ubuntu 18.04 for buliding the appimage. This allows for
using the appimage on older systems that do not provide GLIBC_2.29.
Fixes#19711.
Fixes#20113.
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.
Our previous mangling of gettext broke the `HAVE_WORKING_LIBINTL` test
because it prevented CMake from finding `libintl.h`. Let's fix that by
linking Gettext's `include` directory into `/usr/local` too.
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/)
After some tweaks to our dep builds, we can now build a universal binary
for macOS by using `CMAKE_OSX_ARCHITECTURES`. So, let's do that. This
requires a number of additional changes:
1. We need to build on macOS 11, since earlier versions do not support
building universal (M1 + Intel) binaries.
2. We need to provision a universal `libintl`. The linker will look for
an ARM64 version of this library when linking the `nvim` binary.
While we're here:
1. Link statically to `libintl`. This allows to to avoid having to do
any install name rewriting or codesigning to package Neovim.
2. Bump the `MACOSX_DEPLOYMENT_TARGET` to `11`. We're already using a
`libintl` built by Homebrew (through the pre-installed version of
`gettext`), and that is built for macOS 11.
In order to ensure we link to `libintl.a` instead of `libintl.dylib`, we
have to make sure that CMake can't find the latter. This ideally should
be a matter of doing `brew unlink gettext`. However, CMake is too adept
at finding things that Homebrew has installed (even when not linked), so
we have to do a bit more than that. This appears in the additional step
ensuring static linkage to `libintl`.
We end up breaking some Homebrew-installed software in the process, and
some of these software is called during our build (e.g. curl, git,
wget). To avoid any adverse effects, let's just uninstall them.
Problem:
The release script bundles a system library (CoreServices) that was
added in #18294, which leads to errors on M1 since the architecture is
different from the Github runner.
Solution:
Skip CoreServices when bundling the libraries (as was done for the
CoreFoundation library that #18294 replaced with CoreServices).
* 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.
Since we're not running tests or other things that are more sensitive to
changes in the VM environment, use ubuntu-latest to avoid the busy work
of updating the VM image.
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.
