search

actions / setup-node

Set up your GitHub Actions workflow with a specific version of node.js
MIT License
3.75k stars 1.23k forks source link

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

Open karlhorky opened 6 months ago

karlhorky commented 6 months ago

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:

Runner type:

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 commented 6 months ago

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:

HarithaVattikuti commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

@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 commented 6 months ago

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 commented 5 months ago

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

Screenshot 2024-01-25 at 4 28 52 PM

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 commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 3 months ago

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 commented 3 months ago

@HarithaVattikuti can you reopen this issue please?

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

karlhorky commented 3 months ago

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

aparnajyothi-y commented 3 months ago

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.

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 commented 3 months ago

@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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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:

aparnajyothi-y commented 1 day ago

Hello @karlhorky, We are discussing with the runner-images about the possibility of the cache eviction feature from the runner-images . Please raise an issue in the runner-images repository to request support for this feature as discussed in the above comment and we can add the facility for cache eviction for LTS versions from setup-actions once we receive that feature from runner-images. Please feel free to reach us in case of any further clarifications.

karlhorky commented 23 hours ago

Done, request open here:

mikhailkoliada commented 22 hours ago

@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 :)

karlhorky commented 22 hours ago

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:

  1. LTS releases do not happen very often (still would result in many more cache hits than misses)
  2. 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