-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: new build config section #2163
Comments
I like this approach, sgtm. For the deprecation of the top-level fields; perhaps Compose should add a deprecation policy similar to Engine; https://github.com/docker/docker/blob/master/docs/misc/deprecated.md. This gives users time to adapt, and a clear notice when a feature will be removed, |
+1 can't wait... 💃 |
👍 |
1 similar comment
👍 |
is this option was added to docker-compose? the support for build-args? |
👍 |
👍 |
Working on this in #2540 |
+1 |
Thanks everyone! 👍 Can't wait for this release! |
+1 Really need --build-arg capability with docker-compose!! Will be MOST GLAD when it is added and released! |
@ericm24 +1 :) Can't wait too! :) |
Motivation for this proposal
environment
section isn't applied during the build phaseProposal
Move all build related configuration into a
build:
section in the service. ExampleThis should help clarify the fields that are related to the build phase (and the fields that are not).
Backwards compatibility
On the first release both
build
anddockerfile
would still be allowed at the top level of the service definition. Adockerfile
at the top level would print a deprecation warning.On the following release
dockerfile
at the top level of the service definition would be removed, and it must be under thebuild
section. For trivial cases, a config ofbuild: path/to/context
would still be supported.Related #2111
The text was updated successfully, but these errors were encountered: