The same thing is true when specifying "v12.x". If one wants the latest version one must specify it explicitly. I needed something later than the version 12.16.3 it was grabbing when given "v12.x", so I wrote "v12.18.0" for my node-version. This is not that great though, since I wish to always use the latest release.

nodejs/node-addon-examples#139 (comment)

Hello everyone, just to clarify how it works:

1. actions/setup-node is trying to find version that satisfy your version spec on image
2. If it is found - it is applied (to avoid spending time for downloading).
3. If it is not found, it downloads latest satisfied version and install it in runtime.

Unfortunately, pre-cached versions are updated with small delay (usually, not longer than 1-1.5 weeks because images rollout takes much effort) so if you specify full version, action doesn't find it on image and downloads and installs it in runtime. If you just specify 10.x, it resolves to pre-cached version that can be outdated due to image.

@bryanmacfarlane , may be some flag similar to checkLatest in Azure DevOps UseNode task can be implemented to fix this problem. If checkLatest flag is true, we determine latest version firstly, search it on image and download if it is not found. It will help in cases where 1-2 weeks delay is not acceptable.

Yes, @maxim-lobanov is correct. You can specify the exact version you need and we'll read through the cache and I'm happy to add the checkLatest input to ensure you always have latest. However, realize that using that option will be trading getting the absolute latest (with no latency) for fragility when a new version is released (your scenario) - examples in this issue. We could also consider if checkLatest is specified and it fails, print a warning but fall back to latest in cache. I guess that would make it tryCheckLatest ;)

If you don't mind, I'm going to morph this issue into a tracking item for adding option to always get latest. OK?

@bryanmacfarlane , That sounds good to me!
Probably, we can determine the latest version based on manifest instead of nodejs.org. In this case, we will keep good stability. We are trying to keep manifest up-to-date and upload new versions in 1 day that should be acceptable timeline (considering automation of uploading new versions in future).

@kenhuang

It's not related to #147

You're using v1 ( uses: actions/setup-node@v1) and those changes only went to v2-beta

I think we should enhance the actions/node-versions releases so they are updated everyday. That (1) provides the reliability we get from releases / CDN while at the same time (2) offering new versions with minimal latency. Reading through directly to node dist will completely eliminate the latency but at the same time, it will expose the fragility of failed downtimes when new releases are made from node - the very scenario here.

Hello everyone, just to clarify how it works:

1. actions/setup-node is trying to find version that satisfy your version spec on image
2. If it is found - it is applied (to avoid spending time for downloading).
3. If it is not found, it downloads latest satisfied version and install it in runtime.

Unfortunately, pre-cached versions are updated with small delay (usually, not longer than 1-1.5 weeks because images rollout takes much effort) so if you specify full version, action doesn't find it on image and downloads and installs it in runtime. If you just specify 10.x, it resolves to pre-cached version that can be outdated due to image.

@bryanmacfarlane , may be some flag similar to checkLatest in Azure DevOps UseNode task can be implemented to fix this problem. If checkLatest flag is true, we determine latest version firstly, search it on image and download if it is not found. It will help in cases where 1-2 weeks delay is not acceptable.

This enlightenment was awesome!
Helped me configure my project in just 5 minutes, tks for that @maxim-lobanov =)