Consider including `architecture` in cache keys

[silverwind]

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

[v-HarithaVattikuti]

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

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]

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.

[rlmcneary2]

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

[v-gowridurgad]

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 .

[silverwind]

FYI, ARM runners are already in "public" beta: https://github.blog/changelog/2024-06-03-actions-arm-based-linux-and-windows-runners-are-now-in-public-beta/

[clintonb]

This was fixed by #843 a couple months ago.