Keep configured Dockerfiles outside build context

[IlyaasK]

summary

• write config-supplied Dockerfiles to a temporary directory instead of the source directory
• pass that directory to BuildKit as the Dockerfile local while keeping the source directory as the build context
• preserve existing behavior when the source archive includes its own Dockerfile
• add regression coverage for both Dockerfile paths and the missing-Dockerfile error

why

Writing a generated Dockerfile into the source directory changes the build context. When that Dockerfile contains per-deploy values, COPY . sees a different context on every build and cannot reuse its cached layer. Keeping the Dockerfile frontend input separate leaves identical source contexts identical across repeated builds.

tests

• go test ./lib/builds/builder_agent
• go test -race ./lib/builds/builder_agent
• go vet ./lib/builds/builder_agent
• go test ./lib/builds/... could not initialize in a plain checkout because the embedded Cloud Hypervisor and guest-agent binaries had not been built

---

Note

Low Risk
Isolated builder-agent Dockerfile handling with tests; behavior for in-archive Dockerfiles is preserved.

Overview
Config-supplied Dockerfiles are no longer written into the source tree. prepareDockerfile puts them in a temp directory (with cleanup), while archives that already include a Dockerfile still use the source path unchanged.

runBuild now takes a separate dockerfileDir and baseBuildctlArgs passes --local dockerfile= independently from --local context= (source), so BuildKit’s Dockerfile input does not alter what COPY . sees—improving layer cache reuse when the generated Dockerfile varies per deploy.

Regression tests cover buildctl arg separation, temp-dir vs source Dockerfile paths, source precedence over config, and the missing-Dockerfile error.

^{Reviewed by Cursor Bugbot for commit 9a5a202. Bugbot is set up for automated code reviews on this repo. Configure here.}