`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.
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).
- 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.
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
This reverts commit e71c7898ca.
Triggering jobs on users own fork turned out to be not that useful, and
only necessary in rare moments. It's easier to adjust the CI scripts if
the users wants CI results before creating a pull request. It also
reduces the complexity of the CI code.
This will allow contributors to test changes in their own fork when
pushing without needing to make a pull request. This can be useful when
wanting to test out an idea before initiating a review process.
Make the following assumptions when defining concurrency:
- Pull request will work the same.
- Pushes to the neovim repo will work the same: each unique commit will
trigger a test run that won't cancel each other.
- Pushes to forks will cancel older CI runs on the same branch, similar
to how pull requests work.
This will create duplicate CI runs when doing a pull request, one in the
neovim repo for the pull request event and one in the fork for the push
event. This is an acceptable trade as the runs in the fork doesn't count
towards the CI limit of neovim. Contributors are also free to disable
these actions in their own fork if they wish.
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
8a20f9f98a. 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.
Multi-config generators can be tricky so testing them would be good.
Also test GCC release and MinSizeRel build types as they're prone to
unusual warnings. Remove release testing from test.yml as this is a
sufficient replacement.
Having a workflow that only builds neovim without running all of the
tests is a cheap way to test the build still works without burning too
much CI time.
