Hermetic linux sandbox (and Bazel-initiated file changes) creates spurious hashing on rebuild
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 75
Description
### Description of the bug:
If you build something locally with the hermetic linux sandbox, then build it again without changing anything, Bazel will re-hash all of the input files to the action before realizing there is nothing to do. This appears to be because hardlinking the inputs into the sandbox touches `ctime` without updating Bazel's cache of file information, thus making Bazel think the file might have changed.
The same thing happens with `MODULE.bazel.lock`, though that may be an actual content change. In general, it seems like if Bazel modifies a file, it should update its own filesystem cache to know that it did so.
### Which category does this issue belong to?
Local Execution
### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Check out https://github.com/jkeljo/bazel-hermetic-sandbox-diffawareness-bug and follow the instructions in the README
### Which operating system are you running Bazel on?
Ubuntu 20.04
### What is the output of `bazel info release`?
release 8.4.2
### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.
_No response_
### What's the output of `git remote get-url origin; git rev-parse HEAD` ?
```text
git@github.com:jkeljo/bazel-hermetic-sandbox-diffawareness-bug.git
748c41a99f05bbe659d127d6f6edf153649e70ae
```
### If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
_No response_
### Have you found anything relevant by searching the web?
_No response_
### Any other information, logs, or outputs that you want to share?
_No response_
Contributor guide
Research direction
Start with the reproduction repository's README and confirm the repeated-build hashing behavior on Ubuntu 20.04 with Bazel 8.4.2. Then trace the hermetic Linux sandbox's hardlinking of inputs, the handling of MODULE.bazel.lock, and the filesystem cache updates. Done means an unchanged rebuild no longer re-hashes inputs after sandbox-created or Bazel-initiated file changes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, linux
- Domain
- build-system, operating-systems, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100