lts/* installs old LTS version intermittently

@MaksimZhukov

Description:

Using the following configuration installs Node.js 20.10.0, an old version. Node.js 20.11.0 has been out since 10 Jan 2024.

      - uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'
          check-latest: true

The output looks like this:

Run actions/setup-node@v4
  with:
    node-version: lts/*
    always-auth: false
    check-latest: true
    token: ***
Attempt to resolve LTS alias from manifest...
Found in cache @ /opt/hostedtoolcache/node/20.10.0/x64
Environment details
  node: v20.10.0
  npm: 10.2.3
  yarn: 1.22.21

Action version:

actions/setup-node@v4

Platform:

Ubuntu
macOS
Windows

Runner type:

Hosted
Self-hosted

Tools version:

Node.js lts/*

  node: v20.10.0
  npm: 10.2.3
  yarn: 1.22.21

Repro steps:

Use the configuration above and observe the output above

Expected behavior:

Node.js latest LTS (20.11.0) is installed

Actual behavior:

Node.js older LTS (20.10.0) is installed

cc @MaksimZhukov @dmitry-shibanov @dusan-trickovic

Looks like the manifest might be here (maybe this should be linked in the output of actions/setup-node for easier debugging, if this will continue to be potentially problematic in future?):

https://www.github.com/actions/node-versions/blob/main/versions-manifest.json

I opened a PR there as well, in case that's a better place to discuss:

Add Node.js 20.11.0 node-versions#162

@karlhorky

Hello @karlhorky
Thank you for creating this issue. We will investigate it and get back to you as soon as we have some feedback.

@karlhorky

Hello @karlhorky
The latest version 20.11.0 is merged in node-versions repository. Could you please confirm if the latest version is reflecting at your end.
If you have any concerns please feel free to ping us.

@HarithaVattikuti I just tried re-running my job and it's still on Node.js 20.10.0

Attempt to resolve LTS alias from manifest...
Found in cache @ /opt/hostedtoolcache/node/20.10.0/x64

Is there any way I can manually clear the manifest cache on GitHub Actions?

I know that you can clear other named caches, but these are unrelated to the manifest cache, from what I can tell.

Hello karlhorky, We have tried to reproduce the issue and unable to do so. Below is the screenshot of the same.

Please share a sample repo with minimum code to reproduce the issue.
Feel free to reach out to us in case of any issues

@HarithaVattikuti now it's working, thanks!

Attempt to resolve LTS alias from manifest...
Found in cache @ /opt/hostedtoolcache/node/20.11.0/x64

Maybe I tried it before the change was fully rolled out.

Closing.

Interesting, this is still intermittently failing on some of our repositories (with a macos-12 or macos-13 runner):

Attempt to resolve LTS alias from manifest...
Found in cache @ /Users/runner/hostedtoolcache/node/20.10.0/x64

https://github.com/upleveled/hotline-bling-codealong/actions/runs/7667389682/job/20897108024?pr=164

@HarithaVattikuti maybe there's a problem with the caches?

Reopening for visibility.

@karlhorky

@karlhorky as I was mentioned here, I am no longer a part of GH but still an avid user for my personal belongings, cache eviction should never be done on the runner side, the purpose of the images containing cache is to speed up the basic customer needs but all the management still should be done via the task. Well, surely I can now speak my own opinion based on multiple years of maintenance :)

Ok, I'm not sure of the implementation details or inner workings. But most users won't know / care about that anyway.

Maybe we can agree that node-version: 'lts/*' retrieving an old version is not only a bad UX, but also sometimes a security risk.

The cache being automatically evicted without user interaction when a new Node.js LTS version is released (regardless of where that automatic cache eviction happens) does not seem problematic:

LTS releases do not happen very often (still would result in many more cache hits than misses)
More subjective: being fast for a few users who would get cache misses seems like less of a concern than being correct for all users

@karlhorky

Hello @karlhorky, As @mikhailkoliada mentioned, cache eviction should not be handled on the runner side; instead, cache management should be performed through the task itself. The latest Node.js version, 20.15.1, is available with runner images on both Ubuntu 20 and 22 runners. We are looking for version 20.11.0, which is outdated and Installing the required version at runtime through the workflow is the best workaround.

We are proceeding to close this issue as it is confirmed that cache eviction is not possible through runner-images. Please feel free to reach out if you have any concerns or need further information.

We are proceeding to close this issue as it is confirmed that cache eviction is not possible through runner-images

Where is this confirmed? I opened an issue in actions/runner-images and it's now been assigned:

Cache eviction feature for actions/setup-node runner-images#10311

This issue #940 in actions/setup-node should stay open, because there is still an active bug in actions/setup-node - the following config will intermittently lead to old, stale LTS versions being used:

      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'

This is an unexpected and broken behavior for users, and can lead to security problems.

@aparnajyothi-y Please reconsider leaving this issue open, as it represents an active problem for users, and it should be visible in the issues.

Maybe it should just be publicly recommended to avoid using lts/* and similar version specifiers with actions/setup-node because of this problem.

Probably anything without a fixed version specifier is broken

(at least the way that actions/setup-node is currently built)

Eg. if it's impossible for the teams at GitHub Actions to write code to retrieve the latest Node.js LTS version when a new one is released, maybe users should be suggested to switch to third party alternatives from the community like https://github.com/dcodeIO/setup-node-nvm (GitHub Marketplace)

uses: dcodeIO/setup-node-nvm@master
with:
  node-version: lts/*

Which would work reliably, unlike actions/setup-node.

I opened a PR to add a warning to the readme about NVM syntax here, and steer users away from actions/setup-node if they use this syntax:

Add caveat for version ranges #1114

@aparnajyothi-y I'm not sure why this issue is closed now.

Can you reopen and leave open until it's resolved?

If you close the issue, users will be unable to find this problem, which is still an open, unresolved problem in actions/setup-node.

As an alternative, a new issue could be opened, but that will lose the context / conversation contained in this issue.

@karlhorky

Hello @karlhorky , Thank for your proposals and apologies for the delay in response.
When setup-node action was implemented initially, we designed it to optimize workflow duration to speed up customers' workflows and reduce VM cost for customers. It is why check-latest is disabled by default and action fallbacks to cached version of Node.js on VM. It allows to speed up workflows by 10-15 seconds. Usually, VM cache is up-to-date and it can be 5-6 days old in worst case which is acceptable for the most of customers.

If some customers need to always use the freshest version of Node.js, ""check-latest"" flag is intended for it. If ""check-latest: true"" is passed, action will ignore VM cache and always download latest version.
So, using version: lts/* with check-latest: true will give you exact behaviour which you expect. We have pretty good documentation in repo to explain this behavior: https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md#check-latest-version
We don't have plans to set check-latest: true by default because it will cause increasing action execution duration for all customers because Node.js will always download on-flight.

When setup-node action was implemented initially, we designed it to optimize workflow duration to speed up customers' workflows and reduce VM cost for customers

This is good. Speed and reduction of cost / resource usage is great.

Usually, VM cache is up-to-date and it can be 5-6 days old in worst case which is acceptable for the most of customers.

For the "which is acceptable for most of customers" assertion, where do you get the data from? Have you spoken with a high number of customers who use a version specifier like lts/* and asked whether they think it's ok that it downloads old versions? Or is it just an assumption that you and the team have? Have you considered security releases of Node.js too, where it is often important to upgrade faster?

My assumption would be the opposite - lts/* and other version specifiers downloading old versions because of caching for multiple days is confusing, buggy, broken behavior that will lead users to waste time debugging.

I could imagine a short delay would be acceptable (between 1-3 hours after release), but even that is able to be mitigated with a proper cache design.

If some customers need to always use the freshest version of Node.js, ""check-latest"" flag is intended for it. If ""check-latest: true"" is passed, action will ignore VM cache and always download latest version.
So, using version: lts/* with check-latest: true will give you exact behaviour which you expect.

First of all, if you read the original post again, I used check-latest: true and this was failing to retrieve the latest version. So this feature is also broken (or at least it was, when I reported the issue).

Also, this is *not* the behavior I'm looking for, nor should it be the solution proposed to customers, let me demonstrate:

1. `actions/setup-node@v4` with `node-version: 'lts/*'`

👍 Uses the cache every time - performant
👎 The cache can be multiple days stale, leading to old versions

2. `actions/setup-node@v4` with `node-version: 'lts/*'` and `check-latest: true`

👎 Uses no cache every time - slow
👍 The cache is always fresh

Neither of those options are good. This makes actions/setup-node@v4 an inferior product to other options. I would suggest that the official GitHub Actions setup-node action should be the better product.

I'm proposing a 3rd option, which is in my opinion how the caching should have been designed from the start.

3. `actions/setup-node@v4` with `node-version: 'lts/*'` (new default behavior)

👍 Uses the cache every time - performant
👍 The cache is invalidated remotely, when a new Node.js version is released, leading to fresh versions

There should be no check-latest option.

Actually, maybe there's even more to be improved here, if actions/setup-node changed its design from the manifest + hosted tool cache to the built-in nvm:

It is why check-latest is disabled by default and action fallbacks to cached version of Node.js on VM. It allows to speed up workflows by 10-15 seconds

It only takes 3 additional seconds to download a fresh copy of Node.js via nvm:

`actions/setup-node@v4` with manifest + hosted tool cache

8 seconds total

`nvm` with no Node.js cache

11 seconds total

Don't be confused by actions/cache - in both cases this is used for pnpm store cache - unrelated to the Node.js cache.

So an alternative would be that actions/setup-node could probably be faster by using nvm in some way.

@aparnajyothi-y can you reopen this issue?

It is still a problem - and can be considered a security problem ⚠️:

Node.js v22.13.1 (released 21 Jan 2025) contains security updates
Today (25 Jan 2025) I received Node.js v22.13.0 when using the lts/* alias, not containing these security updates (see logs below)

Run actions/setup-node@v4
  with:
    node-version: lts/*
    always-auth: false
    check-latest: false
    token: ***
  ...
Attempt to resolve LTS alias from manifest...
Found in cache @ /opt/hostedtoolcache/node/22.13.0/x64
Environment details
  node: v22.13.0
  npm: 10.9.2
  yarn: 1.22.22

Or if it's preferred, I can open a new issue, containing a distilled version of the messages above.

Opened a new issue:

Security: lts/* installs old LTS versions up to 1 month+ after release #1236

Add note about NVM and latest release syntax being outdated

Workaround: switch to `nvm`

Full replacement for broken actions/setup-node version resolution, with nvm:

# Use nvm because actions/setup-node does not install latest versions
# https://github.com/actions/setup-node/issues/940
- name: Install latest LTS with nvm
  run: |
    nvm install 'lts/*'
    echo "$(dirname $(nvm which node))" >> $GITHUB_PATH
  shell: bash -l {0}

If you also need pnpm caching (replacement for the cache setting of actions/setup-node), config for actions/cache:

- name: Get pnpm store directory
  shell: bash
  run: |
    echo "STORE_PATH=$(pnpm store path --silent)" >> $GITHUB_ENV
- uses: actions/cache@v4
  name: Setup pnpm cache
  with:
    path: ${{ env.STORE_PATH }}
    key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
    restore-keys: |
      ${{ runner.os }}-pnpm-store-

Also posted on github-tricks: https://github.com/karlhorky/github-tricks/blob/main/readme.md#github-actions-correct-broken-actionssetup-node-version-resolution

Navigation Menu

Repository navigation

`lts/*` installs old LTS version intermittently #940

16 remaining items

1. `actions/setup-node@v4` with `node-version: 'lts/*'`

2. `actions/setup-node@v4` with `node-version: 'lts/*'` and `check-latest: true`

3. `actions/setup-node@v4` with `node-version: 'lts/*'` (new default behavior)

`actions/setup-node@v4` with manifest + hosted tool cache

`nvm` with no Node.js cache

Workaround: switch to `nvm`

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

lts/* installs old LTS version intermittently #940

Description

Activity

karlhorky commented on Jan 12, 2024

v-HarithaVattikuti commented on Jan 12, 2024

v-HarithaVattikuti commented on Jan 17, 2024

karlhorky commented on Jan 17, 2024

karlhorky commented on Jan 17, 2024

v-HarithaVattikuti commented on Jan 25, 2024

karlhorky commented on Jan 26, 2024

karlhorky commented on Jan 26, 2024

16 remaining items

mikhailkoliada commented on Jul 19, 2024

karlhorky commented on Jul 19, 2024

v-aparnajyothi-y commented on Jul 24, 2024

karlhorky commented on Jul 24, 2024

karlhorky commented on Jul 24, 2024

karlhorky commented on Aug 13, 2024

karlhorky commented on Aug 13, 2024

v-aparnajyothi-y commented on Aug 22, 2024

karlhorky commented on Aug 22, 2024

1. actions/setup-node@v4 with node-version: 'lts/*'

2. actions/setup-node@v4 with node-version: 'lts/*' and check-latest: true

3. actions/setup-node@v4 with node-version: 'lts/*' (new default behavior)

karlhorky commented on Aug 22, 2024

actions/setup-node@v4 with manifest + hosted tool cache

nvm with no Node.js cache

karlhorky commented on Jan 25, 2025

karlhorky commented on Jan 27, 2025

karlhorky commented on Aug 2, 2025

Workaround: switch to nvm

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`lts/*` installs old LTS version intermittently #940

1. `actions/setup-node@v4` with `node-version: 'lts/*'`

2. `actions/setup-node@v4` with `node-version: 'lts/*'` and `check-latest: true`

3. `actions/setup-node@v4` with `node-version: 'lts/*'` (new default behavior)

`actions/setup-node@v4` with manifest + hosted tool cache

`nvm` with no Node.js cache

Workaround: switch to `nvm`