`lts/*` installs old LTS version intermittently

[karlhorky]

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:

• [x] Ubuntu
• [ ] macOS
• [ ] Windows

Runner type:

• [x] 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

[karlhorky]

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:

• https://github.com/actions/node-versions/pull/162

[HarithaVattikuti]

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

[HarithaVattikuti]

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.

[karlhorky]

@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

[karlhorky]

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.

[HarithaVattikuti]

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

[karlhorky]

@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.

[karlhorky]

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.

[HarithaVattikuti]

Hello @karlhorky, According to your repository set up-node is run on different OS. The hostedtoolcache will reflect the latest node version from the OS image. For Ex: In MacOS-12 Image Cached Tool of node is 20.11.0 but in MacOS-13 Image cached Tool of node is still 20.10.0. https://github.com/actions/runner-images/blob/macOS-12/20240119.1/images/macos/macos-13-Readme.md#cached-tools https://github.com/actions/runner-images/blob/macOS-12/20240119.1/images/macos/macos-12-Readme.md#cached-tools Please use the related OS image for latest node version 20.11.0. Closing this issue as it is not part of our scope. Feel Free to reach out to us in case of any issues.

[karlhorky]

Oh wow, that's a surprising detail 🤔

To me, it seems like Node.js lts/* should be the latest Node.js LTS, not an older cached version.

If it would be possible to fix that and return the latest LTS, I'm sure that would be widely appreciated and reduce confusion.

[karlhorky]

Update: this continues to be a problem with Node.js v20.12.0 - the lts/* specifier does not install 20.12.0, which has been out for over 5 days now:

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

Logs for the workflow run:

Run actions/setup-node@v4
  
Attempt to resolve LTS alias from manifest...
Found in cache @ /opt/hostedtoolcache/node/20.11.1/x64
Environment details
/home/runner/setup-pnpm/node_modules/.bin/pnpm store path --silent
/home/runner/setup-pnpm/node_modules/.bin/store/v3
Received 0 of 177801572 (0.0%), 0.0 MBs/sec
Received 125829120 of 177801572 (70.8%), 60.0 MBs/sec
Cache Size: ~170 MB (177801572 B)
/usr/bin/tar -xf /home/runner/work/_temp/36665e6f-3c08-4aa9-a645-44132e6[14](https://github.com/upleveled/preflight-test-project-next-js-passing/actions/runs/8507621988/job/23299779905?pr=152#step:7:14)367/cache.tzst -P -C /home/runner/work/preflight-test-project-next-js-passing/preflight-test-project-next-js-passing --use-compress-program unzstd
Received 17780[15](https://github.com/upleveled/preflight-test-project-next-js-passing/actions/runs/8507621988/job/23299779905?pr=152#step:7:16)72 of 177801572 (100.0%), 56.5 MBs/sec
Cache restored successfully
Cache restored from key: node-cache-Linux-pnpm-4ef79db9b37b4913d3034ac221942fa51b304d30abec481a5894d6356c04e3e6

[karlhorky]

@HarithaVattikuti can you reopen this issue please?

Or if not, I'll create a new issue.

[karlhorky]

@aparnajyothi-y if you are taking this over, could you reopen this issue?

[aparnajyothi-y]

Hello @karlhorky, I have tried to run the same job to use lts* in my local and it is downloading the latest version 20.12.0. If a previous LTS version was cached in the runner, actions/setup-node might reuse the cached version instead of fetching the latest one. As a workaround, we need to explicitly setting the cache input to 'none' in the actions/setup-node step of your job. This will prevent actions/setup-node from using a cached version of Node.js. - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: 'lts/*' cache: 'none'

If we want to keep the caching but ensure that always using the latest LTS version then add a step to your workflow that updates Node.js to the latest LTS version after setting it up

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

   - name: Update to latest LTS version
      run: |
        npm install -g n
        sudo n lts
        echo ""NODE_PATH=$(npm root --quiet -g)"" >> $GITHUB_ENV.

[karlhorky]

@aparnajyothi-y what I think should be supported (and what I believe would be the behavior that users would expect and want):

1. lts/* retrieves the latest Node.js LTS version
2. The cache is used when it is available
3. The cache is evicted *without user intervention* when any new LTS version is released (from my understanding, this seems like the area where setup-node or its dependencies/infrastructure could be fixed)
4. No additional configuration such as cache: 'none' is required (also, cache: 'none' is invalid, unrelated configuration)
5. No additional obscure steps (such as installing a Node.js version manager) are required

[aparnajyothi-y]

Hello @karlhorky, We have furthermore investigated and found that the action itself doesn't control the cache, it's managed by the runner environment. Automatic cache eviction may need changes on the runner's side as setup-node uses the caching facilities provided by the runner environment, you can refer here. Automatic cache eviction is a potential feature where old or unused cached dependencies would be automatically removed. This ensures that the cache does not keep growing indefinitely and consume all available storage. Using cache when available is actually a part of the Setup-action's functionality. The action will check if the required Node.js version is in the cache and use it if it's available. By caching these dependencies, subsequent runs of the workflow can be faster as they can reuse the cached dependencies instead of downloading them again. Please let us know in case of any further clarification.

[karlhorky]

I'm not sure I'm understanding what you're saying, but maybe you're saying this bug should be also reported somewhere else?

Where exactly can this be reported also for the runners so that the behavior is automatic cache evictions (or cache upgrades) on new LTS versions?

I and others think that the current behavior is broken, so it should be fixed.

I assume it may not be the runner's responsibility to know about new LTS versions of Node.js (that seems like responsibility of actions/setup-node) - it may actually be a split responsibility: both actions/setup-node and also in the runner environments:

1. To me, it seems that logically, the place that would be related to "performing some action when a new LTS version is released" would be actions/setup-node (this current repo)
2. But in this case, the action needs to evict the cache, where you mentioned the management is the responsibility of the runner

So, if this mental model is correct, there may need to be a "cache eviction API" exposed by the runner, in order for actions/setup-node to be able to evict the cache on new LTS versions.

[aparnajyothi-y]

Hello @karlhorky, As we have mentioned in the above comment, this feature might be shared between the actions/setup-node and the GitHub Actions runner. The actions/setup-node should ideally handle actions related to the release of new LTS versions, while cache management is typically handled by the runner. If we got ""cache eviction API"" support in the runner, that would allow actions like actions/setup-node to evict the cache when new LTS versions are released, ensuring that the cache is always up-to-date. Please let us know in case of any clarification is needed from setup-node. Thank you.

[karlhorky]

Ok great, are you a part of the GitHub Actions team?

Can you reach out to someone internally on the runner side to convey the need for a Cache Eviction API to allow for the actions/setup-node LTS version identifier lts/* to use the latest LTS release without user interaction?

I see that the following people are maintainers / contributors on the public GitHub repos, but I have no visibility / connections beyond that:

• https://github.com/actions/runner
  • @TingluoHuang @luketomlinson @nikola-jokic
• https://github.com/actions/runner-images
  • @Alexey-Ayupov @mikhailkoliada @erik-bershel @MaksimZhukov