| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
- adjust reviewers
- add workflow as cache key
- install attr only when tesitng
- fix s390x workflow by checking out the merge PR instead of master
|
| |
|
|
|
|
|
|
|
| |
This reverts commit e71c7898ca3cf3af1243227ff3cba526d48897e8.
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bumps [actions/checkout](https://github.com/actions/checkout) from 3 to 4.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v3...v4)
---
updated-dependencies:
- dependency-name: actions/checkout
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Only testing the build with external dependencies on build system
changes is too naive, as demonstrated by
b9f19d3e286d95d9209afbc479fa2eb908067fb1.
|
| |
|
|
|
|
| |
Building with Release and RelWithDebInfo build types only on build
system changes is too optimistic, as shown by
https://github.com/neovim/neovim/pull/22436 and
659234c95a23307486a4b7496f3f4391a4bdbe58.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
