IntenseFinance/neovim
3
0
Fork 0
mirror of https://github.com/neovim/neovim.git synced 2025-02-25 18:55:25 -06:00
Code Issues Packages Projects Releases Wiki Activity

docs: misc

Browse Source 
Co-authored-by: Kevin Pham <keevan.pham@gmail.com>
This commit is contained in:
Justin M. Keyes
2023-07-12 19:27:14 +02:00
parent 214b125132
commit d2f8133024
15 changed files with 124 additions and 111 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
MAINTAIN.md
View File

@@ -131,41 +131,46 @@ We may maintain forks, if we are waiting on upstream changes: https://github.com
Non-technical dependencies
--------------------------
* GitHub users:
* https://github.com/marvim
* https://github.com/nvim-winget
* Domain names (held in https://namecheap.com):
* neovim.org
* neovim.io
* packspec.org
* pkgjson.org
* DNS for the above domains is managed in https://cloudflare.com (not the domain registrar)
Automation (CI)
---------------
Our CI and automation jobs are primarily driven by GitHub Actions. Guidelines:
### Backup
### General
Discussions from issues and PRs are backed up here:
https://github.com/neovim/neovim-backup
### Development guidelines
* CI and automation jobs are primarily driven by GitHub Actions.
* Avoid macOS if an Ubuntu or a Windows runner can be used instead. This is
because macOS runners have [tighter restrictions on the number of concurrent
jobs](https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits).
### Runner versions
* For special-purpose jobs where the runner version doesn't really matter,
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 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
produce images that work in the broadest number of environments, and
therefore want to use older releases.
* Runner versions:
* For special-purpose jobs where the runner version doesn't really matter,
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 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
automatically 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 produce images that work in the broadest number of environments,
and therefore want to use older releases.
See also
--------