Remote caching should be a strategy

[jmmv]

Description of the feature request:

When configuring Bazel to use a remote cache without remote execution, the remote cache is not exposed as a strategy as far as I can tell. (Bazel does print remote-cache in the list of strategies when scheduling an action, but this value cannot be explicitly selected via strategy flags, so it is misleading.)

The use of a remote cache should be a strategy that works well with any other strategy, such as dynamic, and can be selectively enabled for individual actions.

What underlying problem are you trying to solve with this feature?

We are facing two issues when remote caching is enabled:

1. It is not possible to configure Bazel so that certain actions use the cache and other actions skip it, yet we need to do this for build performance reasons and to minimize network traffic. The remote-cache magic identifier cannot be passed to --strategy. More context in https://github.com/bazelbuild/bazel/issues/18244.
2. It is not possible to combine the use of remote caching with the dynamic strategy. When remote caching is enabled, as soon as Bazel scores a cache hit for an action, it will patiently wait for the outputs of the action to be downloaded. If you consider a "slow" network and very large artifacts, this is a big problem: many times it's silly to wait for the download because re-running the action locally would have generated the output much sooner.

Which operating system are you running Bazel on?

N/A

What is the output of bazel info release?

bazel-6.1.1

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 master; git rev-parse HEAD ?

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

[larsrc-google]

For point #2, would changing AbstractSpawnStrategy.java:134 to

        spawnRunner.handlesCaching() || stopConcurrentSpawns != null

do it?

[WSUFan]

I have a similar use case where I would like to configure different endpoints for the remote cache and remote executor. For example I have a remote cache service A but remote executor B. The remote executor B has its own implementation of remote cache. And what I want is for Bazel to check the remote cache to see if it has a hit. If not, Bazel will fallback to remote execution, upload all inputs, and let the remote executor perform the jobs. Is this possible in the current version?

[larsrc-google]

@jmmv Forget my previous comment. I'm confused about #2. src/main/java/com/google/devtools/build/lib/exec/AbstractSpawnStrategy.java:144 ought to prevent that problem.

[coeuvre]

I have a similar use case where I would like to configure different endpoints for the remote cache and remote executor. For example I have a remote cache service A but remote executor B. The remote executor B has its own implementation of remote cache. And what I want is for Bazel to check the remote cache to see if it has a hit. If not, Bazel will fallback to remote execution, upload all inputs, and let the remote executor perform the jobs. Is this possible in the current version?

This is possible today. The caveat is your remote executor needs to upload the execution result to your remote cache service. Otherwise, Bazel will fail to fetch them after remote execution.

[github-actions[bot]]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

[csmulhern]

Just wanted to add that I think this is an important feature. For projects with smaller codebases but large dependencies, remote caching is only a win when limiting it to the large dependencies; the small projects can be built much faster locally, and incremental runtimes get dominated by artifact uploading. Today, the only real solution is to manually tag everything with "no-remote-cache-upload", which is not practical.

If remote-cache were a strategy, then I believe this could be accomplished with --strategy_regexp, with e.g. something like --strategy_regexp=^external=remote-cache. Then just the current --spawn_strategy value could be used as a fallback in the case of a cache miss.