lts/* installs old LTS version intermittently
#940
Comments
karlhorky
changed the title
lts/*lts/* installs old LTS version
|
Looks like the manifest might be here (maybe this should be linked in the output of 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: |
|
Hello @karlhorky |
|
Hello @karlhorky |
|
@HarithaVattikuti I just tried re-running my job and it's still on Node.js |
|
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. |
|
@HarithaVattikuti now it's working, thanks! 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 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
changed the title
lts/* installs old LTS versionlts/* installs old LTS version intermittently
|
Hello @karlhorky, |
|
Oh wow, that's a surprising detail 🤔 To me, it seems like Node.js If it would be possible to fix that and return the latest LTS, I'm sure that would be widely appreciated and reduce confusion. |
|
Update: this continues to be a problem with Node.js v20.12.0 - the - name: Use Node.js
uses: actions/setup-node@v4
with:
node-version: 'lts/*'
cache: 'pnpm'Logs for the workflow run: |
|
@HarithaVattikuti can you reopen this issue please? Or if not, I'll create a new issue. |
|
@aparnajyothi-y if you are taking this over, could you reopen this issue? |
|
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 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 |
|
@aparnajyothi-y what I think should be supported (and what I believe would be the behavior that users would expect and want):
|
|
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. |
|
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
So, if this mental model is correct, there may need to be a "cache eviction API" exposed by the runner, in order for |
|
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. |
|
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 I see that the following people are maintainers / contributors on the public GitHub repos, but I have no visibility / connections beyond that: |
|
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. |
|
Done, request open here: |
|
@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 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:
|
|
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. |
Where is this confirmed? I opened an issue in This issue #940 in - 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 Probably anything without a fixed version specifier is broken (at least the way that 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 |
|
I opened a PR to add a warning to the readme about NVM syntax here, and steer users away from |
|
@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 As an alternative, a new issue could be opened, but that will lose the context / conversation contained in this issue. |
WorkaroundFull replacement for broken # 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 - 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 |
|
Hello @karlhorky , Thank for your proposals and apologies for the delay in response. 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. |
This is good. Speed and reduction of cost / resource usage is great.
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 My assumption would be the opposite - 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.
First of all, if you read the original post again, I used Also, this is *not* the behavior I'm looking for, nor should it be the solution proposed to customers, let me demonstrate: 1.
|
|
Actually, maybe there's even more to be improved here, if
It only takes 3 additional seconds to download a fresh copy of Node.js via
|
and others
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.
The output looks like this:
Action version:
actions/setup-node@v4
Platform:
Runner type:
Tools version:
Node.js lts/*
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
The text was updated successfully, but these errors were encountered: