As noted in #21 , hardlinking across drives (say, C: to D:) is not necessary in all cases. Right now, it's a problem only if user opts into node_modules linker.

This action should use the underlying esy binary to figure if hardlinking problem is relevant to the project - if not, it should behave like users expect. ie. place the esy prefix in $HOME/.esy.

I found that those combined are smaller than the .esy folder. Which can get too big and lead to cache misses. E.g. I have projects where that folder is multiple GB and the cache can only take 5GB leading to common cache evictions with a lot of PRs.

Also it seems that that is the recommended way of caching documented in actions/cache: https://github.com/actions/cache/blob/main/examples.md#ocamlreason---esy

If this is on purpose than this issue will just document the intention for others that may be wondering.

Thanks for creating the action :)

Along with #13 , cache failures such as

Error: Unable to reserve cache with key build-darwin-arm64-6e54f555c98a94353c6fe600c1d2a2acb4b678152cb3960d58ae5ccec69c382d-20240515-1, another job may be creating this cache.

ref

.. should not stop other jobs from proceeding. Cache restores are after all optional. They should notify the user, however.

I tried upgrading this action from a much older version, and now I get a bunch of cache failures. For example: https://github.com/grain-lang/libbinaryen/runs/4885304762?check_suite_focus=true

/usr/bin/tar --posix --use-compress-program zstd -T0 -cf cache.tzst -P -C /home/runner/work/libbinaryen/libbinaryen --files-from manifest.txt
385
Error: uploadChunk (start: 402653184, end: 436207615) failed: Cache service responded with 503

This happens consistently.

In #6 we get support for manifest files. However, this change is not present in v1, which is recommended in README.md by default

I see two options to fix the problem

• Use esy/github-action@master instead of v1 in README.md
• Deploy another release v2 with the current changes

What do you think?

Since #24 , we no longer have multiple restore key candidates for cache restore. They were hardcoded in the action source, where as, it should have been a configurable field. Aside, from the fact that it interfered with user's intention cache busting measures.

We need a new configurable field where users can specify a list of restore key candidates.

☝️