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`.
This commit is contained in:
dundargoc 2024-05-11 12:24:10 +02:00 committed by dundargoc
parent e1a81c8d8b
commit c1396afa7c
2 changed files with 8 additions and 9 deletions

View File

@ -23,7 +23,7 @@ env:
jobs: jobs:
old-cmake: old-cmake:
name: Test oldest supported cmake name: Test oldest supported cmake
runs-on: ubuntu-22.04 runs-on: ubuntu-latest
timeout-minutes: 15 timeout-minutes: 15
env: env:
CMAKE_URL: 'https://cmake.org/files/v3.13/cmake-3.13.0-Linux-x86_64.sh' CMAKE_URL: 'https://cmake.org/files/v3.13/cmake-3.13.0-Linux-x86_64.sh'
@ -56,7 +56,7 @@ jobs:
use-existing-src: use-existing-src:
name: Test USE_EXISTING_SRC_DIR=ON builds with no network access name: Test USE_EXISTING_SRC_DIR=ON builds with no network access
runs-on: ubuntu-22.04 runs-on: ubuntu-latest
steps: steps:
- uses: actions/checkout@v4 - uses: actions/checkout@v4
- uses: ./.github/actions/setup - uses: ./.github/actions/setup

View File

@ -215,13 +215,12 @@ https://github.com/neovim/neovim-backup
* For special-purpose jobs where the runner version doesn't really matter, * 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 prefer `-latest` tags so we don't need to manually bump the versions. An
example of a special-purpose workflow is `labeler_pr.yml`. example of a special-purpose workflow is `labeler_pr.yml`.
* For our testing jobs, which are in `test.yml` and `build.yml`, prefer to * For our testing job `test.yml`, prefer to use the latest stable (i.e.
use the latest stable (i.e. non-beta) version explicitly. Avoid using the non-beta) version explicitly. Avoid using the `-latest` tags here as it
`-latest` tags here as it makes it difficult to determine from an makes it difficult to determine from an unrelated PR if a failure is due
unrelated PR if a failure is due to the PR itself or due to GitHub bumping to the PR itself or due to GitHub bumping the `-latest` tag without our
the `-latest` tag without our knowledge. There's also a high risk that knowledge. There's also a high risk that automatically bumping the CI
automatically bumping the CI versions will fail due to manual work being versions will fail due to manual work being required from experience.
required from experience.
* For our release job, which is `release.yml`, prefer to use the oldest * 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 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, trying to produce images that work in the broadest number of environments,