A remote cache can return a result quickly and still return the wrong result. The risk is greatest when an input that affects a build is absent from its declared identity. The launch of the BUILD Foundation puts long-term build infrastructure maintenance in the news. For a team adopting shared caching, the immediate question is more concrete: what makes a cache hit trustworthy?

The runnable example below separates incorrect reuse, legitimate misses, and artifact integrity. 阅读中文版.

What the BUILD Foundation announcement changes

The Linux Foundation announced the BUILD Foundation on October 14, 2026, supporting coordination and maintenance across large-scale, multi-language build and test infrastructure, including the Bazel ecosystem. This is a governance and maintenance event, rather than a compiler release or a cache benchmark.

The practical relevance is continuity for shared rules, toolchains, and documentation. Better maintenance may reduce adoption and upgrade friction, but it does not establish reproducibility for a particular repository. The acceptance method below is an engineering interpretation, not a claim that the foundation has already improved build performance.

A cache key identifies a computation

Think of compilation as a function of source, tools, parameters, and relevant environment. Reuse is justified when those effective inputs are the same. Matching filenames or Git commits may leave out inputs that the actual computation reads. A repository commit is therefore useful context, but not a universal substitute for action identity.

The Bazel remote caching documentation distinguishes an action cache containing result metadata from content-addressed storage containing outputs. Finding the action result and retrieving its corresponding artifacts form a reuse path. Merely finding an artifact somewhere in storage does not establish that it belongs to the current action.

One omitted environment variable is enough

Suppose a build reads MODE and produces different debug and release outputs, but its declared action omits MODE. Both executions have the same key. A release artifact uploaded first can then be returned to a client requesting debug behavior. This is an incomplete input contract, not a cryptographic hash collision.

The Python example deliberately uses a compiler label and string artifacts. A real system needs actual tool identity and a complete dependency contract. Sorted JSON makes this small model inspectable; it is not Bazel’s action serialization, wire format, or remote-cache implementation.

# Teaching model: not Bazel's action serialization or cache client.
import hashlib
import json

def digest(text):
    return hashlib.sha256(text.encode()).hexdigest()

def key(action):
    return digest(json.dumps(action, sort_keys=True, separators=(",", ":")))

def build(source, compiler, mode):
    return f"artifact:{source}:{compiler}:{mode}"

base = {"source": digest("demo"), "compiler": "compiler-v1",
        "flags": ["-O2"], "platform": "demo-platform"}
# MODE affects the result, but the declared action forgets it.
a = build("demo", "compiler-v1", "release")
b = build("demo", "compiler-v1", "debug")
assert a != b
assert key(base) == key(dict(reversed(list(base.items()))))
cache = {key(base): a}
assert cache[key(base)] != b  # A wrong hit, not a hash collision.
release = dict(base, env={"MODE": "release"})
debug = dict(base, env={"MODE": "debug"})
assert key(release) != key(debug)
assert key(base) != key(dict(base, compiler="compiler-v2"))
assert key(base) != key(dict(base, source=digest("changed")))
print("undeclared MODE produces wrong reuse; declared changes alter keys")

The code was executed locally. It checks key stability under dictionary ordering, changes to source and compiler identity, declared environment changes, and incorrect reuse when an environment input is omitted. It neither runs Bazel nor measures build speed or contacts a cache service.

Repair the contract before changing the hash

A longer digest of the same incomplete description still identifies two different computations as the same action. Find the missing effective dependency and either declare it, fix it, or remove its influence. Cryptographic strength and dependency completeness solve different problems.

A version derived from the current clock can vary between executions. A download URL can remain unchanged while its contents change. Make the required version explicit and give dependencies verifiable content identities. This does not mean including every host environment variable: indiscriminate inclusion creates noise without demonstrating that the real dependencies were found.

The Bazel hermeticity guide centers isolation and input identity. A useful repository audit begins with custom scripts and generators. Check whether they read user directories, system tools, undeclared files, or mutable network content. Investigating actual reads is more actionable than treating a hit-rate dashboard as a correctness test.

The key also needs a consistent input snapshot

Another failure can occur after input identity is recorded. Source files change during execution, and the resulting mixed-state artifact is registered under the earlier identity. Every expected field may be present, yet the description and the actual reads no longer match.

The audit therefore asks both whether source identity is included and whether that identity describes the bytes this execution consumed. A controlled workspace or snapshot and appropriate handling of input changes help bind declaration to execution. This is a temporal boundary of the input contract, not something that an extra field alone necessarily fixes.

Distinguish a correct miss from a wrong hit

A change to optimization settings, target platform, or compiler can legitimately invalidate reuse. Removing that identity merely to increase hits trades correctness for a better-looking metric. First decide whether a change should affect the artifact, then remove incidental differences that do not belong in the computation.

Wrong hits are harder to spot in timing reports because they look fast. For selected representative actions, repeat execution in clean environments and compare outputs. Then change one input that should matter and check both identity and output. One successful comparison is evidence about those conditions, not a proof for every platform or task.

Timestamps and other byte differences require explicit interpretation. Decide whether the product needs them before normalizing them away. Preserve raw differences and document any comparison rule. Defining equality after seeing the result can hide a defect rather than establish reproducibility.

A content digest does not establish provenance

Content addressing relates retrieved bytes to their expected digest. It does not, by itself, prove that a trusted process produced the artifact. A faulty or untrusted writer can associate an incorrect result with an action. Complete input declarations and trusted result production remain separate requirements.

Review write access against the team’s existing trust boundary: which jobs may upload, which credentials are available to externally contributed builds, and how exceptional results are handled. No deployment is changed here. The appropriate policy depends on the CI system, cache implementation, and authorization already in place.

Keep action identity, tool identity, result digest, and producer information distinct during investigations. They answer why reuse was allowed, which bytes were returned, and where those bytes came from. Combining them into a generic cache-success flag makes a later incident harder to diagnose.

Decide whether remote caching pays for itself

Establish correct reuse on representative builds before comparing savings with lookup, transfer, and maintenance costs. Large artifacts, slow links, and short local actions can change the outcome. A hit percentage alone cannot establish a wall-clock improvement.

A small acceptance exercise should list key inputs, retain an explainable correct hit and a legitimate invalidation, and record actual end-to-end time and failure behavior. Measurements from your conditions support your decision. The foundation announcement supplies ecosystem context; an individual repository’s suitability still depends on inspectable evidence.

If the input audit and comparison method help you avoid a cache debugging session, voluntary support through the section below is welcome.

Sources and backfill note

Sources: the BUILD Foundation announcement dated October 14, 2026, Bazel remote caching, and Bazel hermeticity. The Google News item is timestamped October 14 at 09:48:07 UTC, before the planned slot. Diagrams and code are original teaching models. Published as a backfill on the evening of October 15; the article date retains the planned 16:00 Beijing slot.