Review Bake parent order before accepting a shared build argument

Bottom line: Treat parent order as part of the build configuration when shared targets assign the same argument. Keep a reusable target’s definition and the value finally accepted by its child separate in review so a later parent does not silently undo an intended customization.

Source fact: documented behavior

The Inheritance in Bake documentation is the primary reference.

Bake targets use inherits to reuse attributes from other targets, and a child can override inherited attributes. When multiple inherited targets conflict, the target appearing last in the inherits list takes precedence. In the documented example, the later _common parent supplies BUILDKIT_CONTEXT_KEEP_GIT_DIR=1 despite an earlier parent assigning 0.

What the source does not establish

This article reviews an inherited build-argument conflict. It does not define every list, map or multi-file merge rule, approve retention of repository metadata or claim that the source’s sample argument is appropriate for a deployment. Keep Dockerfile ARG consumption, runtime environment precedence and variable-validation rules under their separate procedures.

Applicability questions

• Which parents appear in the child’s ordered inherits list?
• Which nonsecret argument is assigned by more than one parent?
• Does the child explicitly override the inherited value?
• What reviewed resolved target should the real pipeline use?

DSE recommendation: trace one conflict through the parent chain

DSE recommends reviewing conflicting inherited build arguments with the ordered parent list and resolved target together.

Draw the relevant inheritance chain from the managed Bake definition. Put each assignment of the selected nonsecret argument beside its target and preserve the list order. Have the build owner identify the intended winning value. Avoid explaining the outcome from file position alone when the child names its parents in a different order.

Inspect the effective target through the installed tool’s documented inspection workflow before executing a release build. Compare the observed argument with the chain and any explicit child override. Keep the resolved result with the exact invocation and definition revision so a local diagnostic target cannot be confused with the pipeline’s selected target.

If the wrong parent wins, choose an explicit reviewed correction. Reorder parents only after assessing the other attributes those parents supply, or apply an appropriate child override when that expresses the design. Do not change several shared targets merely to repair one child without reviewing the effect on their other consumers.

Review the actual build separately after configuration inspection. Require evidence that the intended target and nonsecret argument were used, while leaving secret delivery and resulting application behavior under their own acceptance criteria. Preserve an unexpected resolved value rather than relabeling it as the intended default.

Verification and evidence

Proposed verification, not performed: create two disposable parent targets assigning different harmless values to one build argument. Prepare two children with opposite parent orders and write the expected winning value for each before inspecting them.

Add an explicit child override as a third approved fixture and compare the actual resolved result. Use a harmless marker build only after the model inspection has passed. Retain the parent definitions, ordered lists, child overrides, invocation and observations. These cases examine the documented conflict rule; they do not establish behavior for every attribute type or prove the application’s release tests ran.

Official references

• Inheritance in Bake — Docker Docs.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.