Remote build caching and sandboxing

[marc...@zoox.com]

It appears to me that using remote build caching and building in a sandbox are mutually exclusive. I tested this by taking an external rule that is defined in the WORKSPACE and a separate BUILD file, removing the `hdrs` argument but leaving the `includes` argument in tact, and tried building it in 3 ways:

1) Without caching with spawn_strategy and genrule_strategy set to standalone.
2) Without caching with spawn_strategy and genrule_strategy set to sandboxed.
3) With caching with spawn_strategy and genrule_strategy set to remote.

The first one succeeded and the second one failed as expected. However, the third one succeeded which leads me to believe that remote caching execution is not done in a sandbox.

So my question: Is it possible to use a remote build cache via the `hazelcast_node` argument and build in a sandbox? I'm hoping to improve continuous integration build times by using the build cache but not at the expense of doing unsandboxed builds.

Thanks!

[Alpha Lam]

Hey,

Unfortunately distributed cache implies standalone and sandbox strategy is not used. Theoretically they are not exclusive and I think this can be done.

Alpha

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/15ec1a63-85a2-493c-9d83-cb3c784466e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alpha Lam]

Please file a feature request.

Alpha

[Dan Fabulich]

Filed https://github.com/bazelbuild/bazel/issues/1531

[Dan Fabulich]

A related question I have about this: it seems weird to me that distributed artifact caching is enabled by setting a "strategy." Intuitively, the build strategy has nothing to do with the caching strategy. It seems like artifact caching was inappropriately coupled to remote execution in this design.

[marc...@zoox.com]

Thank you for filing that issue! It was on my todo list but I just hadn't gotten around to it yet.

I agree that the current means of opting in to caching isn't intuitive but I'm not very familiar with the internals so I can't say for sure.

[Alpha Lam]

You're right. Whether cache is used or not should not be coupled with a strategy. It is only in remote spawn strategy so we can test it independently without affecting other strategies. Once we're happy with the design I want to extend to other strategies as well.

Some of the key components are independent from the strategy, e.g. RemoteActionCache. Some refactoring is needed for example generation of the key from an Action to better separate the caching functionality from the remote spawn strategy.

One thing to note is Eric Burnett's team is going to change the architecture for remote caching by using a gRPC interface, instead of embedding a specific cache implementation in Bazel. I would like to hold off these refactoring changes after their stuff is done.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/592d0121-7765-44ba-8966-46caef469b02%40googlegroups.com.