Previously the label was not added if the backport PR was created
manually. The new code is also easier to maintain as it's close to other
label-related code.
(cherry picked from commit 4c788b1757)
Since lintcommit is a required check, it will always need to be run.
However, the lintcommit script is not designed to work on PRs that
doesn't target master branch (and it's not clear whether it's even
desirable).
To circumvent this we create a "dummy" lintcommit check that is run on
release branches that always passes, thus fulfilling the condition of
the required check.
(cherry picked from commit 0500804df5)
Github doesn't allow workflows to be run from the `github-actions`
account, which is the default account. This caused the CI on backport
PRs to not be run. The way to circumvent this is to use a token that
essentially "pretends" to be another user, which in turn triggers the CI
as desired.
Also run lintcommit on release branches as that is now a required check,
meaning it must always be run.
Auto-merging is a useful feature by github, but it requires required
checks which requires a few adjustments. The primary change is that
required checks can't use `paths` or `paths-ignore` as that risks not
running the job, and required checks must always be run.
A workaround for this is to introduce a dummy workflow which is used for
every path not used in the real workflow. That way the required job is
"always" run as far as github is concerned. The workaround is unweildly
so it's only useful to do it for costly workflows where the potential
benefits are big. If not it's better to simply remove any `paths` or
`paths-ignore` from a workflow instead.
(cherry picked from commit 3c803483ac)
`[Backport release-x.y]` will no longer be part of the pull request
title. This means the PR titles will go from looking like
```
[Backport release-0.9] fix(languagetree): remove double recursion in LanguageTree:parse
```
to
```
fix(languagetree): remove double recursion in LanguageTree:parse
```
The benefit of this is that pull requests merged with the "Squash and
Merge" strategy (which uses the PR title as the commit message), will
still follow the conventional commits specification. This will help
tools that rely on conventional commits such as git-cliff.
The `backport` label is added to backported PRs to help distinguish
between backport PRs with regular PRs in the "Pull Requests" tab on
github.
To reduce confusion with the `backport` label, the label to trigger the
backporting has been changed from `backport release-x.y` to
`ci:backport release-x.y`. This is also more consistent with other
labels that trigger a CI job which all use the `ci:` prefix.
Add more filters so that LuaJIT can parse headers on macOS 14.
The system headers use a style of enum introduced in C++11 (and allowed
as an extension in C by clang) of the form:
enum Name : Type {
The system headers also use bitfields in the mach_vm_range_recipe* types:
struct Foo { int bar : 32; }
Neither of these constructs can be parsed by LuaJIT, so filter the lines
out. Neither of these declarations are used by neovim's unittests.
There is a (now closed) issue about bitfields for LuaJIT:
https://github.com/LuaJIT/LuaJIT/issues/951Fixes#26145.
Python 3.12+ throws an error if you try to install a package in an
externally managed environment. Using `--break-system-packages` is not
recommended for personal use, but for CI it should be fine and is
probably the most straightforward solution.
`github.ref` is now defined for both pull requests and pushes, meaning
that it can be used to simplify the concurrency group.
`cancel-in-progress` is set to true only if the trigger is a pull
request, as we don't want master runs to cancel each other out.
Setting the label `ci:skip-news` will skip the job. This is useful for
maintainers to indicate to contributors that a feature isn't big enough
to warrant a news entry, or for contributors who dislike red CI even if
there's nothing wrong.
Also change label `ci-s390x` to `ci:s390x`; this way it'll be easier to
see that `ci:` are a subcategory of labels that affect CI in some way.
Problem:
vim._watch.watchdirs has terrible performance.
Solution:
- On linux use fswatch as a watcher backend if available.
- Add File watcher section to health:vim.lsp. Warn if watchfunc is
libuv-poll.
Problem:
The documentation flow (`gen_vimdoc.py`) has several issues:
- it's not very versatile
- depends on doxygen
- doesn't work well with Lua code as it requires an awkward filter script to convert it into pseudo-C.
- The intermediate XML files and filters makes it too much like a rube goldberg machine.
Solution:
Re-implement the flow using Lua, LPEG and treesitter.
- `gen_vimdoc.py` is now replaced with `gen_vimdoc.lua` and replicates a portion of the logic.
- `lua2dox.lua` is gone!
- No more XML files.
- Doxygen is now longer used and instead we now use:
- LPEG for comment parsing (see `scripts/luacats_grammar.lua` and `scripts/cdoc_grammar.lua`).
- LPEG for C parsing (see `scripts/cdoc_parser.lua`)
- Lua patterns for Lua parsing (see `scripts/luacats_parser.lua`).
- Treesitter for Markdown parsing (see `scripts/text_utils.lua`).
- The generated `runtime/doc/*.mpack` files have been removed.
- `scripts/gen_eval_files.lua` now instead uses `scripts/cdoc_parser.lua` directly.
- Text wrapping is implemented in `scripts/text_utils.lua` and appears to produce more consistent results (the main contributer to the diff of this change).
Splitting it on word boundaries rather than only spaces allows for better
detection. The issue labeler previously didn't catch titles such as
`treesitter: noisy "Invalid node type" error`.
Co-authored-by: casswedson <casswedson@users.noreply.github.com>
Run the release workflow on macos-14 to use faster M1 runners.
Lock the deployment target to the oldest supported version (11.0,
due to libuv support) instead of relying on the host OS version.
Problem: No test coverage on ARM.
Solution: Add `macos-14` tests, which now run on M1. Skip unit tests as these don't work on M1, see #26145. Also test universal build on M1.
Note: `macos-14` will be `macos-latest` in Q2 2024, so we'll want to switch these to keep Intel and unittest coverage on macos (while GH still offers Intel runners).
Explicitly set the build type for both deps and Nvim. They are already
explicitly set on Windows to RelWithDebInfo. Now also explicitly set
them to Debug on POSIX.
- Consistently use the variable CMAKE_BUILD_TYPE to select build type.
- Remove broken `doc_html` target.
- Remove swap files created by oldtest when cleaning.
- Only rerun `lintdoc` if any documentation files has changed.
Github Issue template:
- Add pointers to |dev-tools-backtrace|.
- Add pointers to CONTRIBUTING.md (Reporting Problems), which includes
additional helpful instructions for issue reporting.
- Search existing issues: include label `bug-crash` as well as `bug`.
CONTRIBUTING.md:
- Fix broken link on "stacktrace" after moving to help from wiki.
Summary: Separate the lint job (`make lintdoc`) to validate runtime/doc,
it is no longer as a part of functionaltest (help_spec).
Build (cmake) and CI:
- `make lintdoc`: validate vimdoc files and test-generate HTML docs.
CI will run this as a part of the "docs" workflow.
- `scripts/lintdoc.lua` is added as an entry point (executable script)
for validating vimdoc files.
scripts/gen_help_html.lua:
- Move the tests for validating docs and generating HTMLs from
`help_spec.lua` to `gen_help_html`. Added:
- `gen_help_html.run_validate()`.
- `gen_help_html.test_gen()`.
- Do not hard-code `help_dir` to `build/runtime/doc`, but resolve from
`$VIMRUNTIME`. Therefore, the `make lintdoc` job will check doc files
on `./runtime/doc`, not on `./build/runtime/doc`.
- Add type annotations for gen_help_html.
Problem: When the stable bot automatically closes an issue, the issue
will be marked as "closed as completed". It'd be better to mark the
as "closed as not planned".
Solution: Use `state_reason: "not_planned"` from the issues REST API.
References (REST API):
https://docs.github.com/en/rest/issues/issues?apiVersion=2022-11-28#update-an-issue
Problem: Commits backport-merged to release branches are cherry-picked
from the original commits in the PR from a fork repository, NOT the
actual commit that are merged to neovim/neovim (HEAD). Therefore the
commit reference in the commit message `cherry picked from commit ...`
usually refers to a commit that does NOT exist in the repository,
given that our preferred way of merging PR (rebasing, squashing, etc.)
would rewrite commits.
Solution: Turn on new feature 'detect_merge_method' of backport-action
workflow.
The releases doesn't work on intel mac as libintl isn't available on the system
by default. This makes `:language` not work for the shipped macos releases,
though the reduction in build system complexity most likely outweighs that.
All releases that aren't directly maintained by us should live in the
`neovim/neovim-releases` repository to make it clear that neovim isn't
directly responsible for it and to correctly manage expectations that
it's provided on a best-effort case.
Closes https://github.com/neovim/neovim/issues/26717.
The benefits are primarily being able to use FetchContent, which allows
for a more flexible dependency handling. Other various quality-of-life
features such as `-B` and `-S` flags are also included.
This also removes broken `--version` generation as it does not work for
version 3.10 and 3.11 due to the `JOIN` generator expression.
Reference: https://github.com/neovim/neovim/issues/24004
Notable changes:
- Downloads are significantly faster, upwards of 90% improvement in worst case
scenarios.
- Artifacts can be downloaded from other workflow runs and repositories when
supplied with a PAT.
