mirror of
https://github.com/neovim/neovim.git
synced 2025-09-05 19:08:15 +00:00
ci: split ci.yml into a test workflow and a build test workflow (#22302)
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.
This commit is contained in:
13
MAINTAIN.md
13
MAINTAIN.md
@@ -117,12 +117,13 @@ our CI strategy be. The following guidelines have worked well for us so far:
|
||||
prefer `-latest` tags so we don't need to manually bump the versions. An
|
||||
example of a special-purpose workflow is `labeler.yml`.
|
||||
|
||||
* For our testing jobs, which is currently only `ci.yml`, prefer to use the
|
||||
latest stable (i.e. non-beta) version explicitly. Avoid using the `-latest`
|
||||
tags here as it makes it difficult to determine from an unrelated PR if a
|
||||
failure is due to the PR itself or due to GitHub bumping the `-latest` tag
|
||||
without our knowledge. There's also a high risk that automatic bumping the CI
|
||||
versions will fail due to manual work being required from experience.
|
||||
* For our testing jobs, which are in `test.yml` and `build.yml`, prefer to use
|
||||
the latest stable (i.e. non-beta) version explicitly. Avoid using the
|
||||
`-latest` tags here as it makes it difficult to determine from an unrelated
|
||||
PR if a failure is due to the PR itself or due to GitHub bumping the
|
||||
`-latest` tag without our knowledge. There's also a high risk that automatic
|
||||
bumping the CI versions will fail due to manual work being required from
|
||||
experience.
|
||||
|
||||
* For our release job, which is `release.yml`, prefer to use the oldest stable
|
||||
(i.e. non-deprecated) versions available. The reason is that we're trying to
|
||||
|
Reference in New Issue
Block a user