Skip to content

Build only the subdirectory a service asks for - #21

Merged
csandanov merged 1 commit into
2.0from
codex/build-copy-paths
Aug 19, 2026
Merged

Build only the subdirectory a service asks for#21
csandanov merged 1 commit into
2.0from
codex/build-copy-paths

Conversation

@csandanov

Copy link
Copy Markdown
Member

Summary

--from and --to are pipeline-wide flags: one value for every service in a build. A Drupal build needs . for php and web/ for nginx at the same time, which is why those nginx services still ship a Dockerfile just to write COPY ${COPY_FROM}/${DOCROOT_SUBDIR} ${COPY_TO}/${DOCROOT_SUBDIR}.

The app build configuration now reports a per-service copy path. This places it under the --from / --to roots, so the flags give the roots and the service gives the path within them.

Behaviour

  • A service reporting no copy path builds the whole context, exactly as before.
  • COPY_TO resolves the same way whichever Dockerfile wins, so a service-provided or author Dockerfile declaring ARG COPY_TO sees the same destination as the generated one.
  • An empty root falls back to ., so a copy path alone is enough.

With this, a service that needs only part of the repository no longer has to ship a Dockerfile to say so.

Validation

go build ./... and go test ./cmd/... ./pkg/... pass. New test covers the join across default, explicit, absolute, nested and empty roots and subdirectories.

Requires

The backend change that adds copyFrom / copyTo to the build configuration. Without it both fields are empty and every build behaves exactly as it does today.

An image target that needs one subdirectory of the repository, such as an nginx
service serving only the docroot, could express that only in its own Dockerfile,
because --from and --to are pipeline-wide flags and cannot differ per service
within one build.

Take the copy paths the app build configuration now reports for each service and
place them under the --from and --to roots. A service that reports no copy path
builds the whole context exactly as before, and COPY_TO resolves the same way
whichever Dockerfile wins, so a service-provided or author Dockerfile declaring
ARG COPY_TO sees the same destination as the generated one.

With this, a service that only needs part of the repository no longer has to
ship a Dockerfile to say so.
@csandanov
csandanov merged commit c0ee0a5 into 2.0 Aug 19, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant