Fix Windows cache path validation after Rollup migration

[eitsupi]

Summary

• deduplicate @actions/glob for the GitHub cache provider during Rollup bundling
• keep the warpbuild provider pinned to its own glob dependency
• add save/restore integration tests on Linux, macOS, and Windows that always use new cache keys

Root cause

@actions/cache@6.0.1 depends on @actions/glob@0.6.1, while rust-cache directly depends on @actions/glob@0.7.0. After the Rollup migration, both versions were bundled separately. The older copy uses a CommonJS default import for minimatch; its bundled path matcher returns no matches for existing Windows cache paths. This makes saveCache() report:

Error: Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved.

The existing CI did not detect this because its cache keys were already populated, so post steps exited at Cache up-to-date. without exercising saveCache().

The Rollup resolver now maps only the @actions/cache import of @actions/glob to the direct ESM-compatible 0.7.0 dependency. The warpbuild provider retains its own dependency.

Verification

Before the fix, the new Windows workflow reproduced the path validation error in run 28695048315. After the fix, run 28695186191:

• saved a new Windows cache under a per-run key
• restored that key in a dependent job with full match: true
• passed the GitHub and warpbuild provider workflows on Windows, macOS, and Linux

The regression workflow now covers save and exact restore on all three operating systems.

Test plan

• Windows save job creates a cache under a per-run key
• dependent Windows restore job reports an exact cache hit
• Linux save and exact restore jobs pass
• macOS save and exact restore jobs pass
• Windows matrix save and exact restore jobs pass
• existing GitHub cache workflows remain green
• warpbuild provider remains green on Windows, macOS, and Linux

[Swatinem]

lgtm, though I’m still quite confused why the different versions would behave differently depending on how they are being imported/bundled?
do you know why that is?

[eitsupi]

I think the issue was not that the same version behaved differently depending on how it was imported or bundled, but that a different version of @actions/glob was actually resolved and bundled.
I’m not sure what exact behavioral difference between the @actions/glob versions caused this, though.

[Swatinem]

instead of fixing this in the bundling step, how about using an npm override, so we end up with only one version in the lockfile as well, or rather 2, as I see that warpcache is depending on an even older version there.
Something like https://github.com/Swatinem/rollup-plugin-dts/blob/1fb93d05d64aacb020613751a14ef3a3fb9926fd/package.json#L76-L80

[Swatinem]

looks good, maybe it needs one final rebase, as I was also committing and rebuilding things in the meantime.