perf: remove no-remote-cache execution requirements #2043
Conversation
These were introduced to reduce load on a remote-cache instance to avoid network saturation. A month later, a feature was added in one remote-cache implementatation which provides a different fix: buchgr/bazel-remote#440 rejects large input files on upload. In practice, while these action do often produce huge outputs, they are also slow to re-execute. In many cases it's worth it to use a remote-cache for RunAndCommitLayer in particular to avoid a local rebuild even though it's a large network fetch. Currently users can't configure this because we've hardcoded the values. If they do want to keep the no-remote-cache execution requirement, they can do this via a tag (provided they opt-in to experimental_allow_tags_propagation, see bazelbuild/bazel#8830) #1856 (comment) is an example of a user asking for these to be removed.
|
It might be beneficial for us to document |
|
@sluongng Just wanted to show my interest in hearing the |
|
yes, using |
|
Which mnemonic(s) are you guys using for this? |
|
I'll begin by pointing out that rules_docker has some actions which are doing The Wrong Thing by reading very large inputs and writing very large outputs. rules_oci is a better alternative because we only run actions that only ever operate on a single layer at a time, no "flattening" operations which cause this problem. For example, there should never be an action that takes a base layer as an input, it should just have its digest shuttled around between metadata files. @nkoroste the relevant mnemonics for rules_docker actions that often have huge inputs/outputs are: |
These were introduced to reduce load on a remote-cache instance to avoid network saturation.
A month later, a feature was added in one remote-cache implementatation which provides a different fix:
buchgr/bazel-remote#440 rejects large input files on upload.
In practice, while these action do often produce huge outputs, they are also slow to re-execute.
In many cases it's worth it to use a remote-cache for RunAndCommitLayer in particular to avoid a local rebuild
even though it's a large network fetch.
Currently users can't configure this because we've hardcoded the values. If they do want to keep the
no-remote-cache execution requirement, they can do this via a tag (provided they opt-in to
experimental_allow_tags_propagation, see bazelbuild/bazel#8830)
#1856 (comment) is an example of a user
asking for these to be removed.