Please enable JavaScript.

Coggle requires JavaScript to display documents.

Bazel Remote Caching (A remote cache is used by a team of developers…

- - - - How a build uses remote caching
        
        When you run a Bazel build that can read and write to the remote cache, the build follows these steps:
        
        Bazel creates the graph of targets that need to be built, and then creates a list of required actions. Each of these actions has declared inputs and output filenames
        
        Bazel checks your local machine for existing build outputs and reuses any that it finds
        
        Bazel checks the cache for existing build outputs. If the output is found, Bazel retrieves the output. This is a cache hit
        
        For required actions where the outputs were not found, Bazel executes the actions locally and creates the required build outputs
        
        New build outputs are uploaded to the remote cache
- - - - nginx
        
        nginx is an open source web server. With its WebDAV module, it can be used as a remote cache for Bazel
      - Bazel Remote Cache
        
        Bazel Remote Cache is an open source remote build cache that you can use on your infrastructure.
        
        It is experimental and unsupported
        
        This cache stores contents on disk and also provides garbage collection to enforce an upper storage limit and clean unused artifacts.
        
        The cache is available as a docker image and its code is available on GitHub.
      - Google Cloud Storage
        
        Google Cloud Storage is a fully managed object store which provides an HTTP API that is compatible with Bazel’s remote caching protocol.
        
        It requires that you have a Google Cloud account with billing enabled.
      - Other servers
        
        You can set up any HTTP/1.1 server that supports PUT and GET as the cache’s backend.
        
        Users have reported success with caching backends such as Hazelcast, Apache httpd, and AWS S3
- - - - Read only from the remote cache
        
        to read from the remote cache with sandboxing disabled.
        
        build --remote_cache=http://replace-with-your.host:port
        
        build --remote_upload_local_results=false
        
        build --spawn_strategy=standalone
        
        Using the remote cache with sandboxing enabled is experimental.
        
        Exclude specific targets from using the remote cache
        
        To exclude specific targets from using the remote cache, tag the target with no-cache
        
        java_library(name = "target", tags = ["no-cache"],)
        
        Delete content from the remote cache
        
        Deleting content from the remote cache is part of managing your server.
        
        How you delete content from the remote cache depends on the server you have set up as the cache.
        
        When deleting outputs, either delete the entire cache, or delete old outputs
        
        The cached outputs are stored as a set of names and hashes.
        
        When deleting content, there’s no way to distinguish which output belongs to a specific build
        
        You may want to delete content from the cache to
        
        Create a clean cache after a cache was poisoned
        
        Reduce the amount of storage used by deleting old outputs
- - - - Troubleshooting cache hits
        
        If you are not getting the cache hit rate you are expecting, do the following
        
        Ensure successful communication with the remote endpoint
        
        Check your output for warnings
        
        With remote execution, a failure to talk to the remote endpoint would fail your build.
        
        On the other hand, a cacheable local build would not fail if it cannot cache.
        
        Check the output of your Bazel invocation for warnings, such as:
        
        WARNING: Error reading from the remote cache
        
        WARNING: Error writing to the remote cache:
        
        Such warnings will be followed by the error message detailing the connection problem that should help you debug: for example, mistyped endpoint name or incorrectly set credentials.
        
        Find and address any such errors
        
        ensure that your cache-writing Bazel invocations are able to get cache hits on the same machine and across machines
        
        Ensure your cache-reading Bazel invocations can get cache hits
        
        ensure that they are properly set up to communicate with the remote cache. Ensure the --remote_cache flag is set and there are no warnings in the output
        
        Ensure your cache-reading Bazel invocations build the same targets as the cache-writing Bazel invocations
        
        ensure caching from your cache-writing Bazel invocation to your cache-reading Bazel invocation