In incremental builds, Bazel assumes any digest found to be valid in a previous execution will remain valid for a period of time. In particular, this is true even across invocations with --remote_instance_name set to different values. But if you're switching to a new remote instance, its contents will of course be different, so all cache digests ought to be invalidated. Otherwise, incremental builds with fail with spurious SPAWN(REMOTE_CACHE_EVICTED) errors.
The same may apply to some other flags that control which cache instance Bazel communicates with, like --remote_cache.
Which category does this issue belong to?
Remote Execution
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
No response
Which operating system are you running Bazel on?
No response
What is the output of bazel info release?
No response
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 ?
No response
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?
For Googlers: see b/369413203 for an instance of this bug "poisoning" CI bots.
tpudlik
commented
3 days ago
Description of the bug:
In incremental builds, Bazel assumes any digest found to be valid in a previous execution will remain valid for a period of time. In particular, this is true even across invocations with
--remote_instance_nameset to different values. But if you're switching to a new remote instance, its contents will of course be different, so all cache digests ought to be invalidated. Otherwise, incremental builds with fail with spuriousSPAWN(REMOTE_CACHE_EVICTED)errors.The same may apply to some other flags that control which cache instance Bazel communicates with, like
--remote_cache.Which category does this issue belong to?
Remote Execution
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
No response
Which operating system are you running Bazel on?
No response
What is the output of
bazel info release?No response
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD?No response
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?
For Googlers: see b/369413203 for an instance of this bug "poisoning" CI bots.