Add secrets/configs driver: copy, for use with a remote Docker host

[NAVEENKUMARKR777]

Summary

This has been open since May 2024 with 50+ comments and three separate community PRs (#11871/#12251 by @andoks, #11984/#12448 by @schaubl, and the narrower #12625) all closed without merging. The problem: secrets.<name>.file/configs.<name>.file are interpreted as a path on the Docker host, so Compose bind-mounts it into the container — which breaks entirely once DOCKER_HOST/a docker context points at a remote engine, since Compose is a client-side tool and cannot bind-mount a path that only exists on the client.

Every prior attempt switched the behavior unconditionally based on file: being set, and was rejected for the same reason each time. From @ndeloof's review on #12448:

This PR doesn't address comments on #11867 tl;dr: config/secret file MAY be mounted from (remote) docker host. Many users rely on this, some do even require changes to the original file to be propagated inside container. So we can't just switch to a distinct behavior which would introduce a breaking change. This would at least require an explicit opt-in flag in compose.yaml

This PR adds exactly that: driver: copy as an explicit opt-in.

secrets:
  db_password:
    file: ./db_password.txt
    driver: copy

When set, the file is read from the client's local filesystem and copied into the container once, at creation — reusing the content-injection path Compose already has for content:-based secrets/configs (copyFileToContainer/createTar) — instead of bind-mounted. Without driver: copy, behavior is completely unchanged: existing users who rely on the bind mount (editing the file on the Docker host directly, or watch-driven sync) are unaffected. Any other driver value is still rejected, as before.

New doc page: docs/secrets-and-configs-driver-copy.md.

Test plan

• go test ./pkg/compose/... — new unit tests for resolveFileContent's copy-driver path and precedence (Content/Environment still win), and for the bind-mount-skip/validation logic in buildContainerSecretMounts/buildContainerConfigMounts
• golangci-lint run --build-tags e2e ./... — 0 issues
• New e2e scenario (TestSecretCopyDriver) added but not run in this environment — no Docker daemon available. It specifically verifies the copy is a one-time snapshot (editing the client's file after up does not reach the running container), the key behavioral difference from a bind mount. Please run go test -tags e2e ./pkg/e2e/ -run TestSecretCopyDriver before merging.

Closes #11867

🤖 Generated with Claude Code

[glours]

This account has been blocked after review: it opened a burst of near-identical, AI-generated PRs across many unrelated projects in a very short window, without real review or testing behind them, not a comment on AI-assisted contributions in general, which are welcome here when disclosed and reviewed.