Bazel: Allow for multi-level caching with the gRPC cache and the local disk cache

Created on 20 Jun 2019  路  6Comments  路  Source: bazelbuild/bazel

Description of the feature request:

Feature Request: Allow for multi-level caching with the gRPC cache and the local disk cache

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

A local cache can make builds much faster for developers, especially if they frequently change branches. However, there is no local cache option available for projects using remote build execution. Remote build execution uses a gRPC cache that cannot be used in conjunction with the local disk cache.

This is currently blocking us from using remote build execution at all (the impact on developer productivity from no local caching would be far too high).

Any other information, logs, or outputs that you want to share?

I dug around a bit to see what this would entail. Unlike the local disk cache and the http cache, the gRPC cache isn't implemented as a SimpleBlobStore wrapped by the SimpleBlobStoreActionCache. This is unfortunate because it means we can't use the rather elegant approach @aherrmann used here https://github.com/bazelbuild/bazel/pull/7512

One option is to create a new implementation of AbstractRemoteActionCache that marries the GrpcRemoteCache and a SimpleBlobStoreActionCache. Here is my incomplete attempt at doing this: https://github.com/bazelbuild/bazel/pull/8689 (I haven't figured out how to populate the SimpleBlobStoreActionCache with things fetched from the gRPC cache. Some insight from someone more familiar with how the Bazel action caches work would be awesome).

Another option is to refactor the gRPC cache into a SimpleBlobStore and to then use @aherrmann's approach. I'm not entirely sure what this would entail, but turning the gRPC cache into a SimpleBlobStore would likely be very challenging. There might also be hidden implications to doing so.

team-Remote-Exec feature request untriaged

Most helpful comment

Ah okay. @borkaehw will begin looking into it this week. We'll address questions to you, @ishikhman, if that's alright with you :)

great, thanks! Sure, I'll be happy to help :)

All 6 comments

Thanks a lot for looking into this!

Another option is to refactor the gRPC cache into a SimpleBlobStore and to then use @aherrmann's approach. I'm not entirely sure what this would entail, but turning the gRPC cache into a SimpleBlobStore would likely be very challenging. There might also be hidden implications to doing so.

We had a discussion with @buchgr recently about doing this and it seems to be a logical step to make gRPC cache treated as one of the SimpleBlobStores. There is no good reason why gRPC and Http cache implemented in different ways - it just happened historically, so I do not expect any serious implications here. This will also make code cleaner :)

So I'd suggest to look into the approach of converting the gRPC cache into a SimpleBlobStore.

Ah okay. @borkaehw will begin looking into it this week. We'll address questions to you, @ishikhman, if that's alright with you :)

Ah okay. @borkaehw will begin looking into it this week. We'll address questions to you, @ishikhman, if that's alright with you :)

great, thanks! Sure, I'll be happy to help :)

This is the current state of work https://github.com/bazelbuild/bazel/pull/8740. I have removed GrpcRemoteCache.java from the workspace and replace it with GrpcBlobStore.java. The code compiles, and I am currently testing the code correctness. @ishikhman I appreciate if you can take a look to make sure we are heading to right direction.

Yep! Sorry, forgot to close the issue. The combined cache has been working really well btw :ok_hand:

Was this page helpful?
0 / 5 - 0 ratings