Caching broken on Windows

[ddavisso4]

What happened?

We would like to use rules_js to migrate several custom-webpack-built applications to Bazel. In general it is working as expected. However, given our current infrastructure, a key advantage is the ability to make use of remote (and local disk) caching for both CI and local workflows as a (permanent) precursor to containerization. This too seemed to work okay at first (bazel build then bazel clean then bazel build results in cache hit on 2nd build). However, as soon as the absolute workspace path is different either between hosts or even a different directory on the same host, remote caching breaks (0% hit rate). To add to the fun we have tested it on Linux and things seem to be working as well so based on our inexperienced debugging efforts it seems to have something to do with the runfile magic that is used for Windows.

In an attempt to debug this we found that the example in the repo (located at examples/webpack_cli) exhibits the same behavior. We have analyzed the execution logs are they are identical between different workspaces (except for a couple walltime values). However, running bazel dump --action_cache after successful runs does give different results for action digests (all action keys appear to be identical).

Version

Development (host) and target OS/architectures:
Windows -> Windows

Output of bazel --version:
Bazelisk version: v1.16.0
Aspect CLI version: 5.3.4
Build label: 6.1.2

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file:
We have tried a few different versions, most recently running directly from main

Language(s) and/or frameworks involved:
webpack, js

How to reproduce

1. git clone https://github.com/ddavisso4/rules_js
2. Copy contents to new directory (e.g. rules_js2)
3. cd rules_js
  1. bazel build //examples/webpack_cli:bundle
  2. bazel clean
  3. bazel build //examples/webpack_cli:bundle
  4. Observe that disk cache is used
4. cd ..\rules_js2
  1. bazel build //examples/webpack_cli:bundle
  2. Observe that disk cache is NOT used.

Any other information?

See attached execution logs...
bazel_logs.zip

[jbedard]

Normally we recommend using WSL2 for all windows development due to issues like this. Unless we have funding for such issues we probably won't find time for anything windows specific right now.