Skip to content
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

Consider including architecture in cache keys #1008

Open
silverwind opened this issue Apr 19, 2024 · 6 comments
Open

Consider including architecture in cache keys #1008

silverwind opened this issue Apr 19, 2024 · 6 comments
Labels
feature request New feature or request to improve the current logic

Comments

@silverwind
Copy link

silverwind commented Apr 19, 2024

Description:
The cache keys are currently node-cache-Linux-npm-<hash> which does not seem to include the CPU architecture so if npm dependencies include native binaries and the same cache is restored on a different architecture than what it was built on, these binaries would fail to run.

Action version:
4

Platform:
All

Runner type:
All

Tools version:
All

Repro steps:

  • Build a cache on a x86 runner
  • Restore cache on a ARM runner

Expected behavior:
Cache key should include architecture

Actual behavior:
Cache key does not include architecture

@silverwind silverwind added bug Something isn't working needs triage labels Apr 19, 2024
@silverwind silverwind changed the title Consider including architecture in cache file name Consider including architecture in cache keys Apr 19, 2024
@HarithaVattikuti
Copy link
Contributor

Hello @silverwind
Thank you for creating this issue. We will investigate it and get back to you as soon as we have some feedback.

@sethidden
Copy link

sethidden commented Apr 24, 2024

Can the same be done for Node version as well? If you set up a matrix that runs the same workflow on both e.g. Node 16 and 18, and you have packages like jsdom or canvas which get compiled for a particular Node version like Automattic/node-canvas#1410 , wouldn't the same cache be downloaded for both Node 16 and Node 18, thus causing the linked error?

Let me know if I should make a separate issue

@silverwind
Copy link
Author

silverwind commented Apr 24, 2024

Yes, different node major version have different ABI versions, so I would recommend including node major version in the cache key. Minor/patch versions should be strictly ABI compatible. Also see https://nodejs.org/en/learn/modules/abi-stability.

@gowridurgad gowridurgad self-assigned this May 14, 2024
@rlmcneary2
Copy link

Pretty sure this would resolve a problem with rollup where it uses a binary for a specific architecture. The binary for the first build is cached and then there are failures on subsequent builds if the cached arch. doesn't match the current arch. The workaround is to add the different architecture packages as optional dependencies.

Error: Cannot find module @rollup/rollup-linux-x64-gnu

@gowridurgad
Copy link

Hi @silverwind, Thanks for your valuable suggestion. After analyzing the issue, It seems to be more of a potential feature request rather than a bug. The idea of incorporating the architecture in cache keys could be a significant step in managing npm dependencies with native binaries on various architectures. We've taken your suggestion into consideration for possible future enhancements .

@gowridurgad gowridurgad removed their assignment Jun 13, 2024
@silverwind
Copy link
Author

@HarithaVattikuti HarithaVattikuti added feature request New feature or request to improve the current logic and removed bug Something isn't working labels Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic
Projects
None yet
Development

No branches or pull requests

5 participants