neovim

commit c1396afa7c41c2009d06a54c8aaf1ca5689a9786
parent e1a81c8d8bbbe67710980f0e81aa9473e37defee
Author: dundargoc <gocdundar@gmail.com>
Date:   Sat, 11 May 2024 12:24:10 +0200

ci(build): use latest over explicit image version

These jobs should be safe to just use the latest as there's not many
moving parts as opposed to `test.yml`.

Diffstat:
M
.github/workflows/build.yml
 | 
4
++--
M
MAINTAIN.md
 | 
13
++++++-------

2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
@@ -23,7 +23,7 @@ env:
 jobs:
   old-cmake:
     name: Test oldest supported cmake
-    runs-on: ubuntu-22.04
+    runs-on: ubuntu-latest
     timeout-minutes: 15
     env:
       CMAKE_URL: 'https://cmake.org/files/v3.13/cmake-3.13.0-Linux-x86_64.sh'
@@ -56,7 +56,7 @@ jobs:
 
   use-existing-src:
     name: Test USE_EXISTING_SRC_DIR=ON builds with no network access
-    runs-on: ubuntu-22.04
+    runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
       - uses: ./.github/actions/setup
diff --git a/MAINTAIN.md b/MAINTAIN.md
@@ -215,13 +215,12 @@ https://github.com/neovim/neovim-backup
     * 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_pr.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 testing job `test.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,