-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hosted images are not properly caching versions of node #42
Comments
The "fix" here is to remove 8.10.0 from the Windows tool cache. |
@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 |
@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. |
@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. |
I'll update the image generation scripts to ensure that every time you gen the image the right thing happens.
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.
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: 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. |
@thboop - let's chat tomorrow |
Live site issues with customers blocked: actions/setup-node#77 |
This issue has not had any activity for 45 days and will be closed in 45 days if there continues to be no activity. |
Another node issue today: actions/setup-node#132 (comment) |
Hello! |
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. I am closing the issue, please let me know if you have any concerns or objections |
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
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
The text was updated successfully, but these errors were encountered: