Bottom line: Check what the selected target depends on before treating an earlier stage as completed work. Keep the intended build graph and required checks explicit instead of using the physical order of a Dockerfile as an execution record.
\nThe Multi-stage builds documentation is the primary reference.
\nDocker documents --target as selecting a named stage at which to stop the build. The legacy builder processes stages leading to the selected target even when they are unrelated, while BuildKit builds only the stages on which that target depends. In the guide’s base, stage1 and stage2 example, a BuildKit build targeting stage2 processes base and stage2 and skips independent stage1.
This is a target-dependency review, not proof that an application’s tests passed or that an exported artifact is acceptable. It does not recommend using the legacy builder. Confirm the actual builder and required workflow rather than changing implementations to obtain a preferred example trace.
\nDSE recommends drawing a small stage graph for the Dockerfile under review. Name the selected target and trace the definitions and artifact transfers that connect it to other stages. Have the build owner distinguish dependencies from unrelated alternatives such as diagnostic or development targets.
\nList required preparation and tests beside the graph. Decide whether each belongs in the target’s dependencies or in a separately invoked pipeline task. Keep that decision explicit. Do not call an unused stage a completed quality gate simply because its instructions appear before the production target.
\nReview the actual build invocation with the managed pipeline definition. Retain the target selection and builder identity used by the job that produces the deliverable. Keep local troubleshooting commands separate when they choose a different target. Treat a successful build exit and evidence that the required test task ran as different acceptance observations.
\nIf a missing required step is found, correct the managed workflow through review rather than adding a superficial dependency solely to make a trace longer. Ask the project owner to accept the resulting responsibility for test execution and failure handling. Keep platform selection, final-stage export contents and runtime-dependency checks within their existing separate procedures.
\nProposed verification, not performed: use a disposable Dockerfile patterned on the documented base-and-two-child-stage example, with harmless distinct markers. Predict which markers the selected target requires under the actual approved builder, then collect the build trace.
\nIn a separate revised fixture, make one previously independent stage an intentional dependency and predict the changed graph before rebuilding. Do not infer test execution solely from marker presence inside an artifact. Retain the Dockerfile revision, invocation, builder identity, dependency graph and actual trace. Reconcile the real pipeline’s required checks independently before accepting its deliverable.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Check what the selected target depends on before treating an earlier stage as completed work. Keep the intended build graph and required checks explicit instead of using the physical order of a Dockerfile as an execution record.\nSource fact: documented behavior\nThe Multi-stage builds documentation is the primary reference.\nDocker documents --target as selecting a named stage at which to stop the build. The legacy builder processes stages leading to the selected target even when they are unrelated, while BuildKit builds only the stages on which that target depends. In the guide’s base, stage1 and stage2 example, a BuildKit build targeting stage2 processes base and stage2 and skips independent stage1.\nWhat the source does not establish\nThis is a target-dependency review, not proof that an application’s tests passed or that an exported artifact is acceptable. It does not recommend using the legacy builder. Confirm the actual builder and required workflow rather than changing implementations to obtain a preferred example trace.\nApplicability questions\n\nWhich named stage is the selected target?\nWhich earlier stages are actual dependencies of that target?\nDoes any required preparation or test exist only in an unrelated stage?\nWhich evidence will show the required workflow actually ran?\n\nDSE recommendation: connect required work to the build plan\nDSE recommends drawing a small stage graph for the Dockerfile under review. Name the selected target and trace the definitions and artifact transfers that connect it to other stages. Have the build owner distinguish dependencies from unrelated alternatives such as diagnostic or development targets.\nList required preparation and tests beside the graph. Decide whether each belongs in the target’s dependencies or in a separately invoked pipeline task. Keep that decision explicit. Do not call an unused stage a completed quality gate simply because its instructions appear before the production target.\nReview the actual build invocation with the managed pipeline definition. Retain the target selection and builder identity used by the job that produces the deliverable. Keep local troubleshooting commands separate when they choose a different target. Treat a successful build exit and evidence that the required test task ran as different acceptance observations.\nIf a missing required step is found, correct the managed workflow through review rather than adding a superficial dependency solely to make a trace longer. Ask the project owner to accept the resulting responsibility for test execution and failure handling. Keep platform selection, final-stage export contents and runtime-dependency checks within their existing separate procedures.\nVerification and evidence\nProposed verification, not performed: use a disposable Dockerfile patterned on the documented base-and-two-child-stage example, with harmless distinct markers. Predict which markers the selected target requires under the actual approved builder, then collect the build trace.\nIn a separate revised fixture, make one previously independent stage an intentional dependency and predict the changed graph before rebuilding. Do not infer test execution solely from marker presence inside an artifact. Retain the Dockerfile revision, invocation, builder identity, dependency graph and actual trace. Reconcile the real pipeline’s required checks independently before accepting its deliverable.\nOfficial references\n\nMulti-stage builds — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Check what the selected target depends on before treating an earlier stage as completed work. Keep the intended build graph and required checks explicit instead of using the physical order of a Dockerfile as an execution record.\n\n## Source fact: documented behavior\n\nThe [Multi-stage builds](https://docs.docker.com/build/building/multi-stage/) documentation is the primary reference.\n\nDocker documents --target as selecting a named stage at which to stop the build. The legacy builder processes stages leading to the selected target even when they are unrelated, while BuildKit builds only the stages on which that target depends. In the guide’s base, stage1 and stage2 example, a BuildKit build targeting stage2 processes base and stage2 and skips independent stage1.\n\n## What the source does not establish\n\nThis is a target-dependency review, not proof that an application’s tests passed or that an exported artifact is acceptable. It does not recommend using the legacy builder. Confirm the actual builder and required workflow rather than changing implementations to obtain a preferred example trace.\n\n## Applicability questions\n\n- Which named stage is the selected target?\n\n- Which earlier stages are actual dependencies of that target?\n\n- Does any required preparation or test exist only in an unrelated stage?\n\n- Which evidence will show the required workflow actually ran?\n\n## DSE recommendation: connect required work to the build plan\n\nDSE recommends drawing a small stage graph for the Dockerfile under review. Name the selected target and trace the definitions and artifact transfers that connect it to other stages. Have the build owner distinguish dependencies from unrelated alternatives such as diagnostic or development targets.\n\nList required preparation and tests beside the graph. Decide whether each belongs in the target’s dependencies or in a separately invoked pipeline task. Keep that decision explicit. Do not call an unused stage a completed quality gate simply because its instructions appear before the production target.\n\nReview the actual build invocation with the managed pipeline definition. Retain the target selection and builder identity used by the job that produces the deliverable. Keep local troubleshooting commands separate when they choose a different target. Treat a successful build exit and evidence that the required test task ran as different acceptance observations.\n\nIf a missing required step is found, correct the managed workflow through review rather than adding a superficial dependency solely to make a trace longer. Ask the project owner to accept the resulting responsibility for test execution and failure handling. Keep platform selection, final-stage export contents and runtime-dependency checks within their existing separate procedures.\n\n## Verification and evidence\n\nProposed verification, not performed: use a disposable Dockerfile patterned on the documented base-and-two-child-stage example, with harmless distinct markers. Predict which markers the selected target requires under the actual approved builder, then collect the build trace.\n\nIn a separate revised fixture, make one previously independent stage an intentional dependency and predict the changed graph before rebuilding. Do not infer test execution solely from marker presence inside an artifact. Retain the Dockerfile revision, invocation, builder identity, dependency graph and actual trace. Reconcile the real pipeline’s required checks independently before accepting its deliverable.\n\n## Official references\n\n- [Multi-stage builds](https://docs.docker.com/build/building/multi-stage/) — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/review-docker-build-targets-by-dependency-rather-than-stage-order/", "url": "https://update.dsesecurity.com/updates/review-docker-build-targets-by-dependency-rather-than-stage-order/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/review-docker-build-targets-by-dependency-rather-than-stage-order/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Review Docker build targets by dependency rather than stage order", "item": "https://update.dsesecurity.com/updates/review-docker-build-targets-by-dependency-rather-than-stage-order/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/review-docker-build-targets-by-dependency-rather-than-stage-order/#article", "identifier": "https://update.dsesecurity.com/updates/review-docker-build-targets-by-dependency-rather-than-stage-order/", "url": "https://update.dsesecurity.com/updates/review-docker-build-targets-by-dependency-rather-than-stage-order/", "headline": "Review Docker build targets by dependency rather than stage order", "description": "BuildKit processes the stages needed by the selected target. An unrelated earlier stage can be skipped…", "abstract": "BuildKit processes the stages needed by the selected target. An unrelated earlier stage can be skipped, unlike the legacy-builder behavior documented in the same guide.", "articleBody": "Bottom line: Check what the selected target depends on before treating an earlier stage as completed work. Keep the intended build graph and required checks explicit instead of using the physical order of a Dockerfile as an execution record.\nSource fact: documented behavior\nThe Multi-stage builds documentation is the primary reference.\nDocker documents --target as selecting a named stage at which to stop the build. The legacy builder processes stages leading to the selected target even when they are unrelated, while BuildKit builds only the stages on which that target depends. In the guide’s base, stage1 and stage2 example, a BuildKit build targeting stage2 processes base and stage2 and skips independent stage1.\nWhat the source does not establish\nThis is a target-dependency review, not proof that an application’s tests passed or that an exported artifact is acceptable. It does not recommend using the legacy builder. Confirm the actual builder and required workflow rather than changing implementations to obtain a preferred example trace.\nApplicability questions\n\nWhich named stage is the selected target?\nWhich earlier stages are actual dependencies of that target?\nDoes any required preparation or test exist only in an unrelated stage?\nWhich evidence will show the required workflow actually ran?\n\nDSE recommendation: connect required work to the build plan\nDSE recommends drawing a small stage graph for the Dockerfile under review. Name the selected target and trace the definitions and artifact transfers that connect it to other stages. Have the build owner distinguish dependencies from unrelated alternatives such as diagnostic or development targets.\nList required preparation and tests beside the graph. Decide whether each belongs in the target’s dependencies or in a separately invoked pipeline task. Keep that decision explicit. Do not call an unused stage a completed quality gate simply because its instructions appear before the production target.\nReview the actual build invocation with the managed pipeline definition. Retain the target selection and builder identity used by the job that produces the deliverable. Keep local troubleshooting commands separate when they choose a different target. Treat a successful build exit and evidence that the required test task ran as different acceptance observations.\nIf a missing required step is found, correct the managed workflow through review rather than adding a superficial dependency solely to make a trace longer. Ask the project owner to accept the resulting responsibility for test execution and failure handling. Keep platform selection, final-stage export contents and runtime-dependency checks within their existing separate procedures.\nVerification and evidence\nProposed verification, not performed: use a disposable Dockerfile patterned on the documented base-and-two-child-stage example, with harmless distinct markers. Predict which markers the selected target requires under the actual approved builder, then collect the build trace.\nIn a separate revised fixture, make one previously independent stage an intentional dependency and predict the changed graph before rebuilding. Do not infer test execution solely from marker presence inside an artifact. Retain the Dockerfile revision, invocation, builder identity, dependency graph and actual trace. Reconcile the real pipeline’s required checks independently before accepting its deliverable.\nOfficial references\n\nMulti-stage builds — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T17:40:46+00:00", "dateModified": "2026-10-29T17:41:39+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/review-docker-build-targets-by-dependency-rather-than-stage-order/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/review-docker-build-targets-by-dependency-rather-than-stage-order/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Review Docker build targets by dependency rather than stage order" }, "articleSection": [ "IT" ], "keywords": [ "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 521, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Docker Docs — Multi-stage builds", "url": "https://docs.docker.com/build/building/multi-stage/" } } ] } }