Skip to content

Commit

Permalink
ci(build): use latest over explicit image version
Browse files Browse the repository at this point in the history
These jobs should be safe to just use the latest as there's not many
moving parts as opposed to `test.yml`.
  • Loading branch information
dundargoc committed May 11, 2024
1 parent e1a81c8 commit c1396af
Show file tree
Hide file tree
Showing 2 changed files with 8 additions and 9 deletions.
4 changes: 2 additions & 2 deletions .github/workflows/build.yml
Original file line number Diff line number Diff line change
Expand Up @@ -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'
Expand Down Expand Up @@ -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
Expand Down
13 changes: 6 additions & 7 deletions MAINTAIN.md
Original file line number Diff line number Diff line change
Expand Up @@ -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,
Expand Down

0 comments on commit c1396af

Please sign in to comment.