Docker 27.5 repairs build cache policy inheritance
Docker 27.5 fixes an omitted-value parsing error in build garbage collection and repairs tarball build contexts in the containerd worker.
A build cache policy that omits a storage limit should inherit the configured default. Before Docker Engine 27.5, that omission could instead produce an invalid-size error. The builder tried to parse an empty string before it reached the fallback. The 27.5.0 release notes, dated January 13, include the correction alongside a repair to tarball build contexts with the containerd image store.
The relationship between configuration and the paths that consume it explains both fixes. The garbage collection policy lost the distinction between an absent value and an invalid value. Within the containerd worker, the missing dependency was the transport used to retrieve an uploaded context. Both changes repair an expected operation at an internal boundary.
I value Docker for making build inputs and environments portable between machines. That makes these maintenance changes relevant to how I judge the product. A repeatable build description depends on the builder accepting the same configuration and context through the interfaces people use to submit it.
An absent value failed before inheritance
The garbage collection backport describes the failure precisely. A policy without keepStorage produced could not get builder GC policy: invalid size: ''. The parser treated the missing policy value as an empty size expression. The fallback to defaultKeepStorage existed, but execution failed before it could use it.
The previous workaround was surprising. Setting the policy's keepStorage to the string "0" allowed parsing to succeed and then selected the default. Omitting the field, which expressed the intended inheritance more directly, failed. Two configurations with the same intended meaning behaved differently because of the order of operations in the implementation.
The patch changes that order. It initializes a numeric value to zero and parses keepStorage only when the configuration supplies a nonempty string. The existing zero-value branch then applies defaultKeepStorage. An explicit nonzero policy value continues through the size parser. The change preserves the fallback and makes it reachable for an omitted value.
The pull request supplies this configuration as its manual verification case. The policy defines an age filter while leaving storage inheritance to the enclosing configuration.
{
"builder": {
"gc": {
"enabled": true,
"defaultKeepStorage": "10GB",
"policy": [
{ "filter": ["unused-for=2200h"] }
]
}
}
}
In the reported verification, docker buildx inspect shows the policy with a keep duration of approximately 2200 hours and reserved space of 10 GiB. That output establishes which limit the builder interpreted. The patch also makes errors more specific. Invalid default values receive a failed to parse defaultKeepStorage context, while invalid policy values receive failed to parse keepStorage.
This distinction matters when configuration is generated. A template can intentionally omit a local override and rely on an enclosing default. Requiring a special zero string forces knowledge of an implementation detail into the template. With the fix, the configuration can express inheritance through omission, and malformed supplied values still produce errors.
The release does not introduce a new cache retention algorithm. The patch changes conditional parsing and error reporting. It does not establish a new relationship between the age filter and every other cache policy. Its practical value is that an existing policy can reach the builder with the intended storage value.
Tarball contexts needed their transport
The containerd worker fix repairs another path where the outer interface accepted an operation but the internal implementation lacked a required dependency. The release notes identify tarball build contexts passed to the /build endpoint when the containerd image store is in use.
The pull request explains that a round tripper returns the build context when the context comes directly from a tar archive. This fix adds that round tripper to the containerd worker's source manager. The failure therefore concerns delivery of the build input to the worker. It does not establish that the archive's Dockerfile or application source was invalid.
The author verifies the change with a Terraform Docker provider example that builds an image using the current working directory as its context. That demonstrates why API compatibility matters beyond the interactive Docker command. A tool can submit an ordinary image build through the Engine API and encounter an internal route that requires its own integration work.
For someone investigating this particular failure, the important conditions are the image store and the context submission method. The release identifies the containerd image store specifically. Treating every build failure as a Dockerfile problem would miss the transport dependency that this patch supplies.
My preference for small final images does not reduce the importance of the build machinery. A multi-stage build can leave a single static binary in its final image while still depending on intermediate build inputs. Correct handling of those inputs and their cache policies remains part of producing that small artifact.
Network metadata must survive reconstruction
The network-label backport gives a more specific scope than the release note's short description. It saves and restores labels when Docker recreates Windows networks during daemon startup. Its reproduction creates a labeled network using the nat driver, inspects the label, restarts the Docker service, and inspects the network again.
That sequence separates metadata durability from network creation. A successful initial inspection proves that Docker accepted the label. The second inspection checks whether startup reconstruction preserved it. The repair addresses that reconstruction step, so descriptions of the fix should retain its Windows context.
These changes give 27.5 concrete consequences for build integrations and persisted configuration. The cache patch lets an omitted storage override reach its intended fallback. The containerd patch restores a required context transport, while the Windows networking patch preserves labels across service startup. Each fix makes an existing operation retain the meaning its caller supplied.