Hosted images are not properly caching versions of node

[bryanmacfarlane]

Describe the bug
The windows image has a different version of node installed and cached from the other images making matrix testing inconsistent.

Virtual environments affected

• macOS 10.14
• Ubuntu 16.04 LTS
• Ubuntu 18.04 LTS
• Windows Server 2016 R2
• Windows Server 2019

Expected behavior
A consistent version of node. I realize that timing of images will vary but I don't think that's the issue. I think the image cache and the scripts are inconsistent between the images.

Actual behavior
Insonsistent versions of node.

See: actions/setup-node#27

[kaylangan]

The "fix" here is to remove 8.10.0 from the Windows tool cache.

[bryanmacfarlane]

@kaylangan - I think it is to (1) add the latest version of 8.x to the cache and (2) ensure the every release pulls the latest version at that time of every LTS version still under support into the cache.

Which means 8, 10, and 12: https://nodejs.org/en/about/releases/#releases

[kaylangan]

@bryanmacfarlane actions/setup-node always pulls latest if there's nothing in the cache. Windows is the only OS that actually has Node in the cache, and it only has it for 8.x. My preference would be to remove the cache for Node altogether.

[alepauly]

@bryanmacfarlane , I agree with @kaylangan. we should use the cache as fallback from failure to get latest. that way if the cache goes out of date, customers won't be affected. And so, we really only need to cache minimal set of versions, one (maybe two). As it is, Ubuntu hasn't had a cached version, and Windows only has older 8 which means most builds are already downloading latest.

[bryanmacfarlane]

I'll update the image generation scripts to ensure that every time you gen the image the right thing happens.

setup pulls latest

That's not the way the tool-lib and setup actions / and all the azp installer tasks work

The setup tasks take a semver and we query the cache against the semver pattern (user could specific (^8.0.2 for example) and then if the cache can't satisfy it, we query and go to the service. The doc'd pattern suggests this is how it works and what we guarentee.

Further the azp tasks take an option to query node service for latest so this would break that contract / expectation.

we should eliminate the cache or use as a fallback

That's not what the tool-cache, AZP installer tasks lib or any of the actions and tasks do.

https://github.com/microsoft/azure-pipelines-tool-lib/blob/master/docs/overview.md#tool-cache

documented sequence:
https://github.com/microsoft/azure-pipelines-tool-lib/blob/master/sample.ts#L44

Be aware there's tools like python that we build and we need to cache (can't be easily pulled JIT). Further for major incidents like the one today that took out all actions node customers and blocked them for the better part of a day, this the cache would protect all actions customers who use node from failing when nodejs has an issue. (that's the design) .

Outside of the resiliency issues, this is 20 seconds per leg of common builds that should be instant. This was designed to be very fast in the mainline scenarios and for folks that really care about absolute latest, set the option and pay the cost. Even for those folks for days after we gen an image, even query for latest would resolve to what's in the cache and be fast. Always pulling and failling back in failure modes means you're always slow and with

The default templates have semvers like [8, 10, 12] which means give me one of those versions. We also have a workitem just like AZP to query first.

[bryanmacfarlane]

@thboop - let's chat tomorrow

[bryanmacfarlane]

Live site issues with customers blocked: actions/setup-node#77

[github-actions]

This issue has not had any activity for 45 days and will be closed in 45 days if there continues to be no activity.

[bryanmacfarlane]

relevant links:

https://github.com/microsoft/azure-pipelines-tasks/blob/master/docs/tools.md#hosted-pool

https://nodejs.org/en/about/releases/

[bryanmacfarlane]

Another node issue today: actions/setup-node#132 (comment)

[maxim-lobanov]

Hello!
We are working to add one more caching level for setup-node task to improve stability. We will update issue when it is released

[maxim-lobanov]

We have pre-cached LTS versions of Node.js (8.x, 10.x, 12.x, 14.x) so they should be picked up very quick.
Also setup-node v2-beta was released. It contains stability improvements to install non-cached versions.

I am closing the issue, please let me know if you have any concerns or objections