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: Add support for build-time environment variables to the 'build' API #9176

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
@mapuri
Contributor

mapuri commented Nov 14, 2014

A build-time environment variable is passed to the builder (as part of build API) and made available to the Dockerfile primitives for use in variable expansion and setting up the environment for the RUN primitive (without modifying the Dockerfile and persisting them as environment in the final image).

Following simple example illustrates the feature:

docker build --build-env usr=foo --build-env http_proxy="my.proxy.url" <<EOF
From busybox
USER ${usr:-bar}
RUN git clone <my.private.repo.behind.a.proxy>
EOF

Some of the use cases this PR enables are listed below (captured from comments in the PR's thread).

[Edit: 05/22/2015] A build-time environment variable gets used only while processing the 'RUN' primitive of a DockerFile. Such a variable is only accessible during 'RUN' and is 'not' persisted with the intermediate and final docker images, thereby addressing the portability concerns of the images generated with 'build'.

This addresses issue #4962

+++++++++
Edit: 05/21/2015, 06/26/2015

This PR discussion thread has grown, bringing out use cases that this PR serves and doesn't serves well. Below I consolidate a list of those use cases that have emerged from the comments for ease of reference.

There are two broad usecases that this feature enables:

The following use-case is not served well by this feature and hence not recommended to be used such:

Following use-cases might still be suitable with caching turned off:
#9176 (comment)
#9176 (comment)

@jessfraz

This comment has been minimized.

Show comment
Hide comment
@jessfraz

jessfraz Dec 4, 2014

Contributor

the cmd() function has been removed from the test utils so the tests will need to be updated

Contributor

jessfraz commented Dec 4, 2014

the cmd() function has been removed from the test utils so the tests will need to be updated

@mapuri

This comment has been minimized.

Show comment
Hide comment
@mapuri

mapuri Dec 4, 2014

Contributor

@jfrazelle, thanks for the heads up. I have updated the tests.

Contributor

mapuri commented Dec 4, 2014

@jfrazelle, thanks for the heads up. I have updated the tests.

@SvenDowideit

This comment has been minimized.

Show comment
Hide comment
@SvenDowideit

SvenDowideit Dec 4, 2014

Contributor

I presume that ENV BANANA asd will over-ride the build env value, and that I can persist the build-env values by doing something like RUN export BANANA=$BUILDVAR

All up, nice! - that would allow me to do ...

docker build -e HTTP_PROXY=http://10.10.10.2:4342 -t build ., and for others to add the passwords to access their closed binaries.

which would be useful to add to the apt-cacher-ng article.

Contributor

SvenDowideit commented Dec 4, 2014

I presume that ENV BANANA asd will over-ride the build env value, and that I can persist the build-env values by doing something like RUN export BANANA=$BUILDVAR

All up, nice! - that would allow me to do ...

docker build -e HTTP_PROXY=http://10.10.10.2:4342 -t build ., and for others to add the passwords to access their closed binaries.

which would be useful to add to the apt-cacher-ng article.

@themasterchef

This comment has been minimized.

Show comment
Hide comment
@themasterchef

themasterchef Dec 4, 2014

In our case we are looking at using Docker to build images of our Web services, which need to obtain JARs from a private (but Internet-accessible) Maven (Artifactory) repository at build time. This PR would allow us to set our auth credentials for that Maven repo at build time, using environment variables which only exist at build time, which would be very useful to us!

Additionally, if the Docker Hub Web UI was extended with a little GUI to set these build-time variables, that would allow us to convert manual builds which our devs must currently run on their boxes to automated builds.

themasterchef commented Dec 4, 2014

In our case we are looking at using Docker to build images of our Web services, which need to obtain JARs from a private (but Internet-accessible) Maven (Artifactory) repository at build time. This PR would allow us to set our auth credentials for that Maven repo at build time, using environment variables which only exist at build time, which would be very useful to us!

Additionally, if the Docker Hub Web UI was extended with a little GUI to set these build-time variables, that would allow us to convert manual builds which our devs must currently run on their boxes to automated builds.

@mapuri

This comment has been minimized.

Show comment
Hide comment
@mapuri

mapuri Dec 4, 2014

Contributor

@SvenDowideit

I presume that ENV BANANA asd will over-ride the build env value,

Yes, this PR will allow build env value for BANANA to be overriden by the value provided by ENV statement ('asd' in this case).

and that I can persist the build-env values by doing something like RUN export
BANANA=$BUILDVAR

I am not sure if I understand this presumption. Orthogonal to changes in this PR, I think issuing 'export' during a RUN will not persist the exported environment in the final container itself as it will just be run as a shell command in the context of that RUN statement. And this PR doesn't change anything around that behavior. Am I missing something?

that would allow me to do ...
docker build -e HTTP_PROXY=http://10.10.10.2:4342 -t build ., and for others to add the passwords to access their closed binaries.
which would be useful to add to the apt-cacher-ng article.

Yes, I think this should be addressed by this PR. Were you planning to use persisted environment with 'RUN export' to achieve this?

@themasterchef
Yes, this PR shall address the requirement of passing 'auth' credentials at build time without persisting them.

I have mostly worked with cli interface till now and haven't gotten to familiarizing myself with Docker Hub Web UI. So I just enhanced the cli to start making use of this feature. But I could definitely look into enhancing the web UI as well. Is it ok, if I look into it as a separate issue/PR?

Contributor

mapuri commented Dec 4, 2014

@SvenDowideit

I presume that ENV BANANA asd will over-ride the build env value,

Yes, this PR will allow build env value for BANANA to be overriden by the value provided by ENV statement ('asd' in this case).

and that I can persist the build-env values by doing something like RUN export
BANANA=$BUILDVAR

I am not sure if I understand this presumption. Orthogonal to changes in this PR, I think issuing 'export' during a RUN will not persist the exported environment in the final container itself as it will just be run as a shell command in the context of that RUN statement. And this PR doesn't change anything around that behavior. Am I missing something?

that would allow me to do ...
docker build -e HTTP_PROXY=http://10.10.10.2:4342 -t build ., and for others to add the passwords to access their closed binaries.
which would be useful to add to the apt-cacher-ng article.

Yes, I think this should be addressed by this PR. Were you planning to use persisted environment with 'RUN export' to achieve this?

@themasterchef
Yes, this PR shall address the requirement of passing 'auth' credentials at build time without persisting them.

I have mostly worked with cli interface till now and haven't gotten to familiarizing myself with Docker Hub Web UI. So I just enhanced the cli to start making use of this feature. But I could definitely look into enhancing the web UI as well. Is it ok, if I look into it as a separate issue/PR?

@SvenDowideit

This comment has been minimized.

Show comment
Hide comment
@SvenDowideit

SvenDowideit Dec 5, 2014

Contributor

@mapuri I was wondering mostly about the intended function - and I like it - it would be worth adding a little more of what you've answered here into the documentation.

please also note that the cli.md is the primary docs for commands, and the man pages are shorter summaries.

wrt Hub UI - its not open source but your work will enable things that @themasterchef, I and others would like :)

next up - @shykes @crosbymichael ? design review

Contributor

SvenDowideit commented Dec 5, 2014

@mapuri I was wondering mostly about the intended function - and I like it - it would be worth adding a little more of what you've answered here into the documentation.

please also note that the cli.md is the primary docs for commands, and the man pages are shorter summaries.

wrt Hub UI - its not open source but your work will enable things that @themasterchef, I and others would like :)

next up - @shykes @crosbymichael ? design review

@mapuri

This comment has been minimized.

Show comment
Hide comment
@mapuri

mapuri Dec 5, 2014

Contributor

@SvenDowideit thanks for clarifying and pointers on documentation!

I have updated the cli.md to document more details on the changes. I have also updated docker_remote_api.md and docker_remote_api_v1.16.md to document the optional header, introduced to pass the variables to builder. The hub UI and other remote clients will form and pass this header in order to use this feature. I wasn't sure if this change demands bumping up the API version though, so I just updated v1.16 doc file for now.

Contributor

mapuri commented Dec 5, 2014

@SvenDowideit thanks for clarifying and pointers on documentation!

I have updated the cli.md to document more details on the changes. I have also updated docker_remote_api.md and docker_remote_api_v1.16.md to document the optional header, introduced to pass the variables to builder. The hub UI and other remote clients will form and pass this header in order to use this feature. I wasn't sure if this change demands bumping up the API version though, so I just updated v1.16 doc file for now.

@SvenDowideit

This comment has been minimized.

Show comment
Hide comment
@SvenDowideit

SvenDowideit Dec 15, 2014

Contributor

Docs LGTM - @fredlf @jamtur01

Contributor

SvenDowideit commented Dec 15, 2014

Docs LGTM - @fredlf @jamtur01

@SvenDowideit SvenDowideit changed the title from Add support for build-time environment variables to the 'build' API to Proposal: Add support for build-time environment variables to the 'build' API Dec 15, 2014

@themasterchef

This comment has been minimized.

Show comment
Hide comment
@themasterchef

themasterchef Dec 16, 2014

Looking good, do you have an estimate of when this will be making its way into master? We've just hit the point today where this is feature a really big deal for us.

themasterchef commented Dec 16, 2014

Looking good, do you have an estimate of when this will be making its way into master? We've just hit the point today where this is feature a really big deal for us.

Show outdated Hide outdated docs/sources/reference/api/docker_remote_api.md
`POST /build`
**New!**
This endpoint now optinally takes a serialized array of build-time environment

This comment has been minimized.

@EronWright

EronWright Dec 28, 2014

Spelling mistake here.

@EronWright

EronWright Dec 28, 2014

Spelling mistake here.

This comment has been minimized.

@mapuri

mapuri Jan 1, 2015

Contributor

Thanks for reviewing @EronWright. I have fixed the spelling and updated the diff

@mapuri

mapuri Jan 1, 2015

Contributor

Thanks for reviewing @EronWright. I have fixed the spelling and updated the diff

@SvenDowideit SvenDowideit added the UX label Jan 2, 2015

@dangra

This comment has been minimized.

Show comment
Hide comment
@dangra

dangra Jan 26, 2015

is there any chance to get this released with 1.5.0 ?

dangra commented Jan 26, 2015

is there any chance to get this released with 1.5.0 ?

@mapuri

This comment has been minimized.

Show comment
Hide comment
@mapuri

mapuri Jan 26, 2015

Contributor

@dangra, I am not sure about the feature release process.

Pinging more folks who might be aware as they have been referred or have given inputs earlier in the thread: @shykes @crosbymichael @SvenDowideit @fredlf @jamtur01

Contributor

mapuri commented Jan 26, 2015

@dangra, I am not sure about the feature release process.

Pinging more folks who might be aware as they have been referred or have given inputs earlier in the thread: @shykes @crosbymichael @SvenDowideit @fredlf @jamtur01

@pniederlag

This comment has been minimized.

Show comment
Hide comment
@pniederlag

pniederlag Jan 27, 2015

Please merge this, it would help improve docker usability very much by speeding up the development cycle in a portable way.

pniederlag commented Jan 27, 2015

Please merge this, it would help improve docker usability very much by speeding up the development cycle in a portable way.

@dangra

This comment has been minimized.

Show comment
Hide comment
@dangra

dangra Jan 27, 2015

Please merge this, it would help improve docker usability very much by speeding up the development cycle in a portable way.

👍

dangra commented Jan 27, 2015

Please merge this, it would help improve docker usability very much by speeding up the development cycle in a portable way.

👍

@duglin

This comment has been minimized.

Show comment
Hide comment
@duglin

duglin Jan 28, 2015

Contributor

Can we get a test that uses the env-file form?

Contributor

duglin commented Jan 28, 2015

Can we get a test that uses the env-file form?

@mapuri

This comment has been minimized.

Show comment
Hide comment
@mapuri

mapuri Jan 28, 2015

Contributor

@duglin, sure I will add a test for env-file.

Contributor

mapuri commented Jan 28, 2015

@duglin, sure I will add a test for env-file.

@brahmaroutu

This comment has been minimized.

Show comment
Hide comment
@brahmaroutu

brahmaroutu Jan 28, 2015

Contributor

+1

Contributor

brahmaroutu commented Jan 28, 2015

+1

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael Jan 28, 2015

Contributor

@dangra Not for 1.5, the feature freeze was last week.

Contributor

crosbymichael commented Jan 28, 2015

@dangra Not for 1.5, the feature freeze was last week.

@mapuri

This comment has been minimized.

Show comment
Hide comment
@mapuri

mapuri Jan 28, 2015

Contributor

@duglin and all, I have updated the diff with a test for env-file. Please review and let me know your comments.

Contributor

mapuri commented Jan 28, 2015

@duglin and all, I have updated the diff with a test for env-file. Please review and let me know your comments.

Show outdated Hide outdated builder/dispatchers.go
@@ -226,10 +226,16 @@ func run(b *Builder, args []string, attributes map[string]bool, original string)
// set Cmd manually, this is special case only for Dockerfiles
b.Config.Cmd = config.Cmd
runconfig.Merge(b.Config, config)
// set build-time environment for 'run'. We let dockerfile
// environment override build-time environment.
env := b.Config.Env

This comment has been minimized.

@duglin

duglin Jan 28, 2015

Contributor

if I'm following this correctly, you're adding the env vars that the user set on the cmd line when they issued the "docker build". But, you're only adding it to the BuildContext for the RUN command. Why not add it to the BuildContext's env so it applies to all commands? Granted RUN is probably the only one that will directly use it, but by making it global to the build context you can then use those env vars for variable substitutions in other commands. For example, if someone does:
ADD $foo /tmp/
we'll expand $foo - but I don't think your code will work for this case. Do I have that right?

@duglin

duglin Jan 28, 2015

Contributor

if I'm following this correctly, you're adding the env vars that the user set on the cmd line when they issued the "docker build". But, you're only adding it to the BuildContext for the RUN command. Why not add it to the BuildContext's env so it applies to all commands? Granted RUN is probably the only one that will directly use it, but by making it global to the build context you can then use those env vars for variable substitutions in other commands. For example, if someone does:
ADD $foo /tmp/
we'll expand $foo - but I don't think your code will work for this case. Do I have that right?

This comment has been minimized.

@duglin

duglin Jan 28, 2015

Contributor

And, this makes we realize that we should add another test(s) to verify that those env vars are available during this substitution step I mentioned.

@duglin

duglin Jan 28, 2015

Contributor

And, this makes we realize that we should add another test(s) to verify that those env vars are available during this substitution step I mentioned.

This comment has been minimized.

@mapuri

mapuri Jan 29, 2015

Contributor

@duglin, you got it right. This proposal does introduce build time env-vars to setup the environment required for the RUN primitive which involves running a command, script etc while addressing portability concerns as raised in issue #4962 around effects of persisting such values in final/intermediate images. This proposal however doesn't change or address anything around notion of expansion of other variables/symbols that are/shall be supported by Dockerfile otherwise.

I think what you ask is support for the latter. While it technically sounds doable I would not like to overlap the notion of environment variables be mixed with variables/symbol for expansion since the two serve different purposes and might be better implemented as separate command-line options.

If there is a value add to have variables/symbols for expansion in other primitives and available through command-line, I would be happy to investigate. Let me know.

Hope this clarifies.

Just a side note, while looking at the code for handling ADD primitive (in file builder/dispatchers.go) I couldn't find the logic for variable expansion. Most likely I missed some code path, could you kindly point me to relevant code if you are aware, just to enhance my understanding.

@mapuri

mapuri Jan 29, 2015

Contributor

@duglin, you got it right. This proposal does introduce build time env-vars to setup the environment required for the RUN primitive which involves running a command, script etc while addressing portability concerns as raised in issue #4962 around effects of persisting such values in final/intermediate images. This proposal however doesn't change or address anything around notion of expansion of other variables/symbols that are/shall be supported by Dockerfile otherwise.

I think what you ask is support for the latter. While it technically sounds doable I would not like to overlap the notion of environment variables be mixed with variables/symbol for expansion since the two serve different purposes and might be better implemented as separate command-line options.

If there is a value add to have variables/symbols for expansion in other primitives and available through command-line, I would be happy to investigate. Let me know.

Hope this clarifies.

Just a side note, while looking at the code for handling ADD primitive (in file builder/dispatchers.go) I couldn't find the logic for variable expansion. Most likely I missed some code path, could you kindly point me to relevant code if you are aware, just to enhance my understanding.

This comment has been minimized.

@duglin

duglin Jan 29, 2015

Contributor

re: expansion - see https://github.com/docker/docker/blob/master/builder/support.go#L18 and then look for where that method is called.

To the other points, I need to think more about this because I may be incorrectly mixing topics and purposes. The reason I thought of this was because I could image someone wanting their Dockerfile to have something like:
COPY files-${arch}/Makefile /home/user/
where a different Makefile is copied based on the value of "arch" - meaning "x86" vs "arm". So, I thought it would be nice if they could run:
docker build -e arch=arm .
But, my proposal sets 'arch' in the container too which is probably a bad thing based on the original issue/thread.

I may need to just "deal with it" but it feels odd to have env vars that only apply to certain Dockerfile commands and not all of them.
I wonder if the notion of "build-time env vars" is something to consider. Meaning, we create a sibling to b.Config.Env called b.Config.BuildEnv and those are available for variable expansion during the processing of the Dockerfile (and passed into the RUN command) but are NOT set within the container.

@erikh your thoughts?

@duglin

duglin Jan 29, 2015

Contributor

re: expansion - see https://github.com/docker/docker/blob/master/builder/support.go#L18 and then look for where that method is called.

To the other points, I need to think more about this because I may be incorrectly mixing topics and purposes. The reason I thought of this was because I could image someone wanting their Dockerfile to have something like:
COPY files-${arch}/Makefile /home/user/
where a different Makefile is copied based on the value of "arch" - meaning "x86" vs "arm". So, I thought it would be nice if they could run:
docker build -e arch=arm .
But, my proposal sets 'arch' in the container too which is probably a bad thing based on the original issue/thread.

I may need to just "deal with it" but it feels odd to have env vars that only apply to certain Dockerfile commands and not all of them.
I wonder if the notion of "build-time env vars" is something to consider. Meaning, we create a sibling to b.Config.Env called b.Config.BuildEnv and those are available for variable expansion during the processing of the Dockerfile (and passed into the RUN command) but are NOT set within the container.

@erikh your thoughts?

This comment has been minimized.

@erikh

erikh Jan 29, 2015

Contributor

We can’t do this because of repeatability and idempotency concerns.

Basically, the dockerfile cannot depend on external input other than the context. This is there to ensure repositories can be built by anyone without knowing any specific method to build.

-Erik

On Jan 29, 2015, at 4:59 AM, Doug Davis notifications@github.com wrote:

In builder/dispatchers.go #9176 (comment):

@@ -226,10 +226,16 @@ func run(b *Builder, args []string, attributes map[string]bool, original string)
// set Cmd manually, this is special case only for Dockerfiles
b.Config.Cmd = config.Cmd
runconfig.Merge(b.Config, config)

To the other points, I need to think more about this because I may be incorrectly mixing topics and purposes. The reason I thought of this was because I could image someone wanting their Dockerfile to have something like:
COPY files-${arch}/Makefile /home/user/
where a different Makefile is copied based on the value of "arch" - meaning "x86" vs "arm". So, I thought it would be nice if they could run:
docker build -e arch=arm .
But, my proposal sets 'arch' in the container too which is probably a bad thing based on the original issue/thread.

I may need to just "deal with it" but it feels odd to have env vars that only apply to certain Dockerfile commands and not all of them.

I wonder if the notion of "build-time env vars" is something to consider. Meaning, we create a sibling to b.Config.Env called b.Config.BuildEnv and those are available for variable expansion during the processing of the Dockerfile (and passed into the RUN command) but are NOT set within the container.

@erikh https://github.com/erikh your thoughts?


Reply to this email directly or view it on GitHub https://github.com/docker/docker/pull/9176/files#r23765400.

@erikh

erikh Jan 29, 2015

Contributor

We can’t do this because of repeatability and idempotency concerns.

Basically, the dockerfile cannot depend on external input other than the context. This is there to ensure repositories can be built by anyone without knowing any specific method to build.

-Erik

On Jan 29, 2015, at 4:59 AM, Doug Davis notifications@github.com wrote:

In builder/dispatchers.go #9176 (comment):

@@ -226,10 +226,16 @@ func run(b *Builder, args []string, attributes map[string]bool, original string)
// set Cmd manually, this is special case only for Dockerfiles
b.Config.Cmd = config.Cmd
runconfig.Merge(b.Config, config)

To the other points, I need to think more about this because I may be incorrectly mixing topics and purposes. The reason I thought of this was because I could image someone wanting their Dockerfile to have something like:
COPY files-${arch}/Makefile /home/user/
where a different Makefile is copied based on the value of "arch" - meaning "x86" vs "arm". So, I thought it would be nice if they could run:
docker build -e arch=arm .
But, my proposal sets 'arch' in the container too which is probably a bad thing based on the original issue/thread.

I may need to just "deal with it" but it feels odd to have env vars that only apply to certain Dockerfile commands and not all of them.

I wonder if the notion of "build-time env vars" is something to consider. Meaning, we create a sibling to b.Config.Env called b.Config.BuildEnv and those are available for variable expansion during the processing of the Dockerfile (and passed into the RUN command) but are NOT set within the container.

@erikh https://github.com/erikh your thoughts?


Reply to this email directly or view it on GitHub https://github.com/docker/docker/pull/9176/files#r23765400.

This comment has been minimized.

@duglin

duglin Jan 29, 2015

Contributor

By "this" do you mean my proposal or this entire PR? Because even setting env vars for RUN would seem to violate what you said.

@duglin

duglin Jan 29, 2015

Contributor

By "this" do you mean my proposal or this entire PR? Because even setting env vars for RUN would seem to violate what you said.

Show outdated Hide outdated docs/man/docker-build.1.md
**-e**, **--env**=*environment*
Set build-time environment variables. This option allows you to specify
arbitrary environment variables that are available for the command(s) that will
be executed as part of 'RUN' primitive of Dockerfile. Such a variable is only

This comment has been minimized.

@duglin

duglin Jan 28, 2015

Contributor

I think this would need to change too based on how we want the env vars to be available for more than just RUN.

@duglin

duglin Jan 28, 2015

Contributor

I think this would need to change too based on how we want the env vars to be available for more than just RUN.

Show outdated Hide outdated docs/sources/reference/api/docker_remote_api_v1.16.md
- **X-Registry-Config** – base64-encoded ConfigFile object
- **X-BuildEnv** – base64-encoded JSON array of strings of build-time environment
variables in the form <var>=<value>. These can be accessed like regular
environment variables in the 'RUN' primitive of the Dockerfile. And they are

This comment has been minimized.

@duglin

duglin Jan 28, 2015

Contributor

Would need to modify this too to make it less RUN specific

@duglin

duglin Jan 28, 2015

Contributor

Would need to modify this too to make it less RUN specific

Show outdated Hide outdated docs/sources/reference/commandline/cli.md
$ docker build -e HTTP_PROXY=http://10.20.30.2:1234 .
This will allow passing the built-time environment variables, that can be
accessed like regular environment variables in the 'RUN' primitive of the

This comment has been minimized.

@duglin

duglin Jan 28, 2015

Contributor

and here too

@duglin

duglin Jan 28, 2015

Contributor

and here too

Show outdated Hide outdated integration-cli/docker_cli_build_test.go
runCmd := exec.Command(dockerBinary, "run", "bldenvtest")
if out, _, err := runCommandWithOutput(runCmd); out != "\n" || err != nil {
t.Fatalf("run produced invalid output: '%q', expected '%q'", out, "")

This comment has been minimized.

@duglin

duglin Jan 28, 2015

Contributor

%q already puts quotes around it so you don't need to add your own

@duglin

duglin Jan 28, 2015

Contributor

%q already puts quotes around it so you don't need to add your own

This comment has been minimized.

@mapuri

mapuri Jan 29, 2015

Contributor

Thanks for catching this. I will make the change.

@mapuri

mapuri Jan 29, 2015

Contributor

Thanks for catching this. I will make the change.

Show outdated Hide outdated integration-cli/docker_cli_build_test.go
runCmd := exec.Command(dockerBinary, "run", "bldenvtest")
if out, _, err := runCommandWithOutput(runCmd); out != "\n" || err != nil {
t.Fatalf("run produced invalid output: '%q', expected '%q'", out, "")

This comment has been minimized.

@duglin

duglin Jan 28, 2015

Contributor

quotes again

@duglin

duglin Jan 28, 2015

Contributor

quotes again

This comment has been minimized.

@mapuri

mapuri Jan 29, 2015

Contributor

I will make the change.

@mapuri

mapuri Jan 29, 2015

Contributor

I will make the change.

Show outdated Hide outdated integration-cli/docker_cli_build_test.go
runCmd := exec.Command(dockerBinary, "run", "bldenvtest")
if out, _, err := runCommandWithOutput(runCmd); !strings.Contains(out, envValOveride) || err != nil {
t.Fatalf("run produced invalid output: '%q', expected '%q'", out, envValOveride)

This comment has been minimized.

@duglin

duglin Jan 28, 2015

Contributor

remove quotes

@duglin

duglin Jan 28, 2015

Contributor

remove quotes

This comment has been minimized.

@mapuri

mapuri Jan 29, 2015

Contributor

I will make the change.

@mapuri

mapuri Jan 29, 2015

Contributor

I will make the change.

@erikh

This comment has been minimized.

Show comment
Hide comment
@erikh

erikh Jan 29, 2015

Contributor

Please see my notes here: #9176 (comment)

The problem with this patch is that it introduces external context; for example, how is our Automated Build system supposed to work with environment variables which may alter the execution of the dockerfile in some way?

I'm sorry but I'm a big -1 for this patch.

/cc @tiborvass

-Erik

Contributor

erikh commented Jan 29, 2015

Please see my notes here: #9176 (comment)

The problem with this patch is that it introduces external context; for example, how is our Automated Build system supposed to work with environment variables which may alter the execution of the dockerfile in some way?

I'm sorry but I'm a big -1 for this patch.

/cc @tiborvass

-Erik

@duglin

This comment has been minimized.

Show comment
Hide comment
@duglin

duglin Jan 29, 2015

Contributor

@erikh I tend to look at this problem in the same way we look at Dockerfiles. Meaning, if you want things to work "out of the box" w/o any external dependencies then there are certain rules you need to play by. In particular, your Dockerfile MUST be named "Dockerfile" and you can't depend on someone passing in additional info (like via an env var).

However, there are cases where people are ok to not live within those rules and are willing to live with the consequences. For example, we support the -f option for the Dockerfile name now. So, yes if I name it something else it won't work in the dockerhub automated system but that's the choice I made because it does work in "my" automated build system.

I view "build-only env vars" in the same way. The person defining them is willing to live with the consequences because they need the additional capability it provides. In the case I'm thinking of, I'm going to need it to control the build process. Meaning, based on external information I need the Dockerfile build processing to vary. This is why we were discussing the IF/ENDIF logic the other day. The conditional part of that must be controlled by some external information otherwise there would be no need for the IF at all since everything would be known in advance.

The "COPY files-${arch}/Makefile /home/user/" example I gave earlier is something that I can see people wanting to leverage and I'm not sure how to else solve that issue unless we use something like what this PR is proposing. Is there another way to introduce variability into the Dockerfile file processing that I'm not thinking of?

Contributor

duglin commented Jan 29, 2015

@erikh I tend to look at this problem in the same way we look at Dockerfiles. Meaning, if you want things to work "out of the box" w/o any external dependencies then there are certain rules you need to play by. In particular, your Dockerfile MUST be named "Dockerfile" and you can't depend on someone passing in additional info (like via an env var).

However, there are cases where people are ok to not live within those rules and are willing to live with the consequences. For example, we support the -f option for the Dockerfile name now. So, yes if I name it something else it won't work in the dockerhub automated system but that's the choice I made because it does work in "my" automated build system.

I view "build-only env vars" in the same way. The person defining them is willing to live with the consequences because they need the additional capability it provides. In the case I'm thinking of, I'm going to need it to control the build process. Meaning, based on external information I need the Dockerfile build processing to vary. This is why we were discussing the IF/ENDIF logic the other day. The conditional part of that must be controlled by some external information otherwise there would be no need for the IF at all since everything would be known in advance.

The "COPY files-${arch}/Makefile /home/user/" example I gave earlier is something that I can see people wanting to leverage and I'm not sure how to else solve that issue unless we use something like what this PR is proposing. Is there another way to introduce variability into the Dockerfile file processing that I'm not thinking of?

@mapuri

This comment has been minimized.

Show comment
Hide comment
@mapuri

mapuri Jan 29, 2015

Contributor

@erikh,
I agree with how @duglin describes the requirement of "build-only env vars". It gives the necessary flexibility to the user of a DockerFile (who might not always be the author/maintainer of the Dockerfile) to pass the env-vars required to suit their build environment. Actually this missing flexibility is an issue that I hit while trying to build docker in my environment which required http-proxy to be set (#4962 (comment)) and I see other folks also having expressed similar use-cases but there is no good way to handle this in Docker. I had to hard-code the environment in Dockerfile and maintain my own version of it Or integrate with other tools like #4962 (comment)

You asked:

how is our Automated Build system supposed to work with environment variables which may alter the execution of the dockerfile in some way?

I would like to reply to this with my own concrete example. Since this patch only passes the environment context to the RUN primitive, it takes effect only if one is specified otherwise the existing systems shall work as is. On the other hand, with this change I am now able to enhance the 'Makefile' for the docker build to pass environment variables something like this, which is a more repeatable and dynamic for different build environments (my office (behind proxy) and home (no proxy) to name a few in my case) and it still produces a final image that can be used across different production environments:

build: bundles
docker build -e HTTP_PROXY=$(HTTP_PROXY) -t "$(DOCKER_IMAGE)" .

and docker make can be invoked in my office environment like:
make build HTTP_PROXY="my.proxy.url"

and docker make can be invoked in my home environment like:
make build

Contributor

mapuri commented Jan 29, 2015

@erikh,
I agree with how @duglin describes the requirement of "build-only env vars". It gives the necessary flexibility to the user of a DockerFile (who might not always be the author/maintainer of the Dockerfile) to pass the env-vars required to suit their build environment. Actually this missing flexibility is an issue that I hit while trying to build docker in my environment which required http-proxy to be set (#4962 (comment)) and I see other folks also having expressed similar use-cases but there is no good way to handle this in Docker. I had to hard-code the environment in Dockerfile and maintain my own version of it Or integrate with other tools like #4962 (comment)

You asked:

how is our Automated Build system supposed to work with environment variables which may alter the execution of the dockerfile in some way?

I would like to reply to this with my own concrete example. Since this patch only passes the environment context to the RUN primitive, it takes effect only if one is specified otherwise the existing systems shall work as is. On the other hand, with this change I am now able to enhance the 'Makefile' for the docker build to pass environment variables something like this, which is a more repeatable and dynamic for different build environments (my office (behind proxy) and home (no proxy) to name a few in my case) and it still produces a final image that can be used across different production environments:

build: bundles
docker build -e HTTP_PROXY=$(HTTP_PROXY) -t "$(DOCKER_IMAGE)" .

and docker make can be invoked in my office environment like:
make build HTTP_PROXY="my.proxy.url"

and docker make can be invoked in my home environment like:
make build

@pniederlag

This comment has been minimized.

Show comment
Hide comment
@pniederlag

pniederlag Jan 29, 2015

@erikh It is a matter of fact that building images from Dockerfiles might need adaptions for different environments. Passing them in transparently during build-time gives users a chance to keep the Dockerfile clean and "dockerhub ready". If the user is required to inject http_proxy via a persistent variable makes the Dockerfile as well as the resulting image way less generic. This feature, good documentation plus 'it must build on dockerhub without this feature' would help users.

Do you have an alternative way to use an http_proxy during build time?

pniederlag commented Jan 29, 2015

@erikh It is a matter of fact that building images from Dockerfiles might need adaptions for different environments. Passing them in transparently during build-time gives users a chance to keep the Dockerfile clean and "dockerhub ready". If the user is required to inject http_proxy via a persistent variable makes the Dockerfile as well as the resulting image way less generic. This feature, good documentation plus 'it must build on dockerhub without this feature' would help users.

Do you have an alternative way to use an http_proxy during build time?

@erikh

This comment has been minimized.

Show comment
Hide comment
@erikh

erikh Jan 29, 2015

Contributor

I don’t, but neither does the automated build system.

-Erik

On Jan 29, 2015, at 9:58 AM, Peter Niederlag notifications@github.com wrote:

@erikh https://github.com/erikh It is a matter of fact that building images from Dockerfiles might need adaptions for different environments. Passing them in transparently during build-time gives users a chance to keep the Dockerfile clean and "dockerhub ready". If the user is required to inject http_proxy via a persistent variable makes the Dockerfile as well as the resulting image way less generic. This feature, good documentation plus 'it must build on dockerhub without this feature' would help users.

Do you have an alternative way to use an http_proxy during build time?


Reply to this email directly or view it on GitHub #9176 (comment).

Contributor

erikh commented Jan 29, 2015

I don’t, but neither does the automated build system.

-Erik

On Jan 29, 2015, at 9:58 AM, Peter Niederlag notifications@github.com wrote:

@erikh https://github.com/erikh It is a matter of fact that building images from Dockerfiles might need adaptions for different environments. Passing them in transparently during build-time gives users a chance to keep the Dockerfile clean and "dockerhub ready". If the user is required to inject http_proxy via a persistent variable makes the Dockerfile as well as the resulting image way less generic. This feature, good documentation plus 'it must build on dockerhub without this feature' would help users.

Do you have an alternative way to use an http_proxy during build time?


Reply to this email directly or view it on GitHub #9176 (comment).

@dustinlacewell

This comment has been minimized.

Show comment
Hide comment
@dustinlacewell

dustinlacewell Jan 29, 2015

As far as exposing configurable environment variables on the DockerHub front-end, I don't really see any inherent reason why we wouldn't be able to eventually develop that.

dustinlacewell commented Jan 29, 2015

As far as exposing configurable environment variables on the DockerHub front-end, I don't really see any inherent reason why we wouldn't be able to eventually develop that.

@SvenDowideit

This comment has been minimized.

Show comment
Hide comment
@SvenDowideit

SvenDowideit Feb 2, 2015

Contributor

One really big reason I like this proposal, (and then adding support for it to the automated builds), is that it would allow not only setting things like HTTP_PROXY, but also adding authentication tokens / passwords into a Dockerfile without them then also being in the image.

That way, I can have a Dockerfile that does a git clone of multiple private repositories, import non-general access binary packages, and generally do what I need, without those secrets then being stored in the resulting image.

@shykes is there a possibility of an indicative design yes-maybe-changethis-no?

Contributor

SvenDowideit commented Feb 2, 2015

One really big reason I like this proposal, (and then adding support for it to the automated builds), is that it would allow not only setting things like HTTP_PROXY, but also adding authentication tokens / passwords into a Dockerfile without them then also being in the image.

That way, I can have a Dockerfile that does a git clone of multiple private repositories, import non-general access binary packages, and generally do what I need, without those secrets then being stored in the resulting image.

@shykes is there a possibility of an indicative design yes-maybe-changethis-no?

@erikh

This comment has been minimized.

Show comment
Hide comment
@erikh

erikh Feb 2, 2015

Contributor

Sorry for the bad paste…

15:35:16          +erikh | tianon: tibor: duglin: I'm thinking more about volume and env flags to docker build
15:35:28          +erikh | and I'm wondering if we couldn't do it something like this                                                                                                                                                                                                                        │
15:35:38          +erikh | if VOLUME or ENV are declared, they are candidates for the flags                                                                                                                                                                                                                  │
15:35:44          +erikh | e.g., they have defaults                                                                                                                                                                                                                                                          │
15:36:13          +erikh | then we could have -e and -v like they are in docker run, but without *depending* on external context. opt-in

On Feb 1, 2015, at 6:06 PM, Sven Dowideit notifications@github.com wrote:

One really big reason I like this proposal, (and then adding support for it to the automated builds), is that it would allow not only setting things like HTTP_PROXY, but also adding authentication tokens / passwords into a Dockerfile without them then also being in the image.

That way, I can have a Dockerfile that does a git clone of multiple private repositories, import non-general access binary packages, and generally do what I need, without those secrets then being stored in the resulting image.

@shykes https://github.com/shykes is there a possibility of an indicative design yes-maybe-changethis-no?


Reply to this email directly or view it on GitHub #9176 (comment).

Contributor

erikh commented Feb 2, 2015

Sorry for the bad paste…

15:35:16          +erikh | tianon: tibor: duglin: I'm thinking more about volume and env flags to docker build
15:35:28          +erikh | and I'm wondering if we couldn't do it something like this                                                                                                                                                                                                                        │
15:35:38          +erikh | if VOLUME or ENV are declared, they are candidates for the flags                                                                                                                                                                                                                  │
15:35:44          +erikh | e.g., they have defaults                                                                                                                                                                                                                                                          │
15:36:13          +erikh | then we could have -e and -v like they are in docker run, but without *depending* on external context. opt-in

On Feb 1, 2015, at 6:06 PM, Sven Dowideit notifications@github.com wrote:

One really big reason I like this proposal, (and then adding support for it to the automated builds), is that it would allow not only setting things like HTTP_PROXY, but also adding authentication tokens / passwords into a Dockerfile without them then also being in the image.

That way, I can have a Dockerfile that does a git clone of multiple private repositories, import non-general access binary packages, and generally do what I need, without those secrets then being stored in the resulting image.

@shykes https://github.com/shykes is there a possibility of an indicative design yes-maybe-changethis-no?


Reply to this email directly or view it on GitHub #9176 (comment).

@marcellodesales

This comment has been minimized.

Show comment
Hide comment
@marcellodesales

marcellodesales Jul 3, 2015

@mapuri How can I test your Pull Request??? Can you specify what I would need to do with "docker build" in the example above? I'm willing to build Docker from your fork and verify in my environment...

thanks
Marcello

marcellodesales commented Jul 3, 2015

@mapuri How can I test your Pull Request??? Can you specify what I would need to do with "docker build" in the example above? I'm willing to build Docker from your fork and verify in my environment...

thanks
Marcello

@mapuri

This comment has been minimized.

Show comment
Hide comment
@mapuri

mapuri Jul 3, 2015

Contributor

@marcellodesales

With this patch, you can pass the proxy-info as follows:

docker build --build-env http_proxy=<proxy url> --build-env https_proxy=<proxy url> <path-to-docker-file>

HTH

Contributor

mapuri commented Jul 3, 2015

@marcellodesales

With this patch, you can pass the proxy-info as follows:

docker build --build-env http_proxy=<proxy url> --build-env https_proxy=<proxy url> <path-to-docker-file>

HTH

@marcellodesales

This comment has been minimized.

Show comment
Hide comment
@marcellodesales

marcellodesales Jul 3, 2015

@mapuri perfect... Did you generate any binary, by the way, before I build local?

marcellodesales commented Jul 3, 2015

@mapuri perfect... Did you generate any binary, by the way, before I build local?

@mapuri

This comment has been minimized.

Show comment
Hide comment
@mapuri

mapuri Jul 3, 2015

Contributor

you mean a docker binary with this patch? No, I don't have one ready :( .

It should be easy to build locally though. You just need to pull my fork: https://github.com/mapuri/docker.git and issue sudo make binary from the workspace root. The docker binary gets generated at bundles/latest/binary/

Contributor

mapuri commented Jul 3, 2015

you mean a docker binary with this patch? No, I don't have one ready :( .

It should be easy to build locally though. You just need to pull my fork: https://github.com/mapuri/docker.git and issue sudo make binary from the workspace root. The docker binary gets generated at bundles/latest/binary/

@marcellodesales

This comment has been minimized.

Show comment
Hide comment
@marcellodesales

marcellodesales Jul 3, 2015

@mapuri Awesome... I just went out for dinner and I'm back... Will continue on it right now...

marcellodesales commented Jul 3, 2015

@mapuri Awesome... I just went out for dinner and I'm back... Will continue on it right now...

@JeanMertz

This comment has been minimized.

Show comment
Hide comment
@JeanMertz

JeanMertz Jul 3, 2015

Please keep this discussion on-focus. This is not a mailinglist.

JeanMertz commented Jul 3, 2015

Please keep this discussion on-focus. This is not a mailinglist.

@apatrida

This comment has been minimized.

Show comment
Hide comment
@apatrida

apatrida Jul 3, 2015

+1 for something that solves at least one use case listed here. It is only 8 months old and will continue to collect use cases like dust.

apatrida commented Jul 3, 2015

+1 for something that solves at least one use case listed here. It is only 8 months old and will continue to collect use cases like dust.

@psolbach

This comment has been minimized.

Show comment
Hide comment
@psolbach

psolbach Jul 4, 2015

+1, nobody flags builds unknowingly. The reasoning against this PR is high concept over function.

psolbach commented Jul 4, 2015

+1, nobody flags builds unknowingly. The reasoning against this PR is high concept over function.

@marcellodesales

This comment has been minimized.

Show comment
Hide comment
@marcellodesales

marcellodesales Jul 4, 2015

@JeanMertz, sorry about that...

@mapuri, I built and I have tested it in my environment... Let me know if everything is ok with the build...

# root at pppdc9prd8wu in /tmp/stackedit on git:master x [8:42:27]
$ docker --version
Docker version 1.8.0-dev, build 8ae8b0d

# root at pppdc9prd8wu in /tmp/stackedit on git:master x [8:42:25]
$ docker info
Containers: 13
Images: 29
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-229.4.2.el7.x86_64
Operating System: Red Hat Enterprise Linux
CPUs: 2
Total Memory: 7.641 GiB
Name: pppdc9prd8wu
ID: 3M2F:QYY7:Z5DI:YTVI:RAV4:SHPM:C3RC:CWIY:FHFA:ZYAS:SNHG:CMTY
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

The build environments were properly injected into the build process... Yes, we made progress here... However there are a few things to think about... (For whatever reason, the build is not connecting to GitHub and my host has the same problem, so checking)...

# root at pppdc9prd8wu in /tmp/stackedit on git:master x [8:35:11]
$ docker build --no-cache=true --build-env http_proxy=$http_proxy --build-env https_proxy=$https_proxy --build-env no_proxy=$no_proxy --build-env HTTP_PROXY=$HTTP_PROXY --build-env HTTPS_PROXY=$HTTPS_PROXY --build-env NO_PROXY=$NO_PROXY .
Sending build context to Docker daemon 40.85 MB
Step 0 : FROM node:0.12
 ---> 20a32f7a591c
Step 1 : RUN echo $HTTP_PROXY
 ---> Running in 0d5aa7d28ca1
http://qypprdproxy02.ie.intuit.net:80
 ---> 698348cc941f
Removing intermediate container 0d5aa7d28ca1
Step 2 : RUN npm config set proxy $HTTP_PROXY
 ---> Running in 98a09526b5d4
 ---> 937d442b3d42
Removing intermediate container 98a09526b5d4
Step 3 : COPY package.json /tmp/package.json
 ---> 3f7ca0058762
Removing intermediate container ebc82497c3c1
Step 4 : RUN cd /tmp && npm install
 ---> Running in b1981597b5dd
npm WARN deprecated gulp-clean@0.3.1: use gulp-rimraf instead
npm ERR! git clone --template=/root/.npm/_git-remotes/_templates --mirror git://github.com/benweet/gulp-inject.git /root/.npm/_git-remotes/git-github-com-benweet-gulp-inject-git-e1282b7e: Cloning into bare repository '/root/.npm/_git-remotes/git-github-com-benweet-gulp-inject-git-e1282b7e'...
npm ERR! git clone --template=/root/.npm/_git-remotes/_templates --mirror git://github.com/benweet/gulp-inject.git /root/.npm/_git-remotes/git-github-com-benweet-gulp-inject-git-e1282b7e: fatal: unable to connect to github.com:
npm ERR! git clone --template=/root/.npm/_git-remotes/_templates --mirror git://github.com/benweet/gulp-inject.git /root/.npm/_git-remotes/git-github-com-benweet-gulp-inject-git-e1282b7e: github.com[0: 192.30.252.128]: errno=Connection timed out
npm ERR! Linux 3.10.0-229.4.2.el7.x86_64
npm ERR! argv "node" "/usr/local/bin/npm" "install"
npm ERR! node v0.12.5
npm ERR! npm  v2.11.3
npm ERR! code 128
The command '/bin/sh -c cd /tmp && npm install' returned a non-zero code: 1

At first gland it looks like it works... But my host is behind the firewall, and I can only go out through the HTTP_PROXY... So, I might have something weird configured...

So, the design of the Dockerfile might also influence on this... Some systems like NPM require us to issue a command to setup the registry... http://jjasonclark.com/how-to-setup-node-behind-web-proxy/

As there is NO way to conditionally execute Dockerfile instruction during build, how could we address that @mapuri ???

# Pull base image.
FROM node:0.12

RUN echo $HTTP_PROXY
# Should only run when the environment has it set (ONLY RUN IF $HTTP_PROXY was provided) 
RUN npm config set proxy $HTTP_PROXY

COPY package.json /tmp/package.json

RUN cd /tmp && npm install

# Node base will default the command to `node server.js`.

# Expose port.
EXPOSE 3000

marcellodesales commented Jul 4, 2015

@JeanMertz, sorry about that...

@mapuri, I built and I have tested it in my environment... Let me know if everything is ok with the build...

# root at pppdc9prd8wu in /tmp/stackedit on git:master x [8:42:27]
$ docker --version
Docker version 1.8.0-dev, build 8ae8b0d

# root at pppdc9prd8wu in /tmp/stackedit on git:master x [8:42:25]
$ docker info
Containers: 13
Images: 29
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-229.4.2.el7.x86_64
Operating System: Red Hat Enterprise Linux
CPUs: 2
Total Memory: 7.641 GiB
Name: pppdc9prd8wu
ID: 3M2F:QYY7:Z5DI:YTVI:RAV4:SHPM:C3RC:CWIY:FHFA:ZYAS:SNHG:CMTY
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

The build environments were properly injected into the build process... Yes, we made progress here... However there are a few things to think about... (For whatever reason, the build is not connecting to GitHub and my host has the same problem, so checking)...

# root at pppdc9prd8wu in /tmp/stackedit on git:master x [8:35:11]
$ docker build --no-cache=true --build-env http_proxy=$http_proxy --build-env https_proxy=$https_proxy --build-env no_proxy=$no_proxy --build-env HTTP_PROXY=$HTTP_PROXY --build-env HTTPS_PROXY=$HTTPS_PROXY --build-env NO_PROXY=$NO_PROXY .
Sending build context to Docker daemon 40.85 MB
Step 0 : FROM node:0.12
 ---> 20a32f7a591c
Step 1 : RUN echo $HTTP_PROXY
 ---> Running in 0d5aa7d28ca1
http://qypprdproxy02.ie.intuit.net:80
 ---> 698348cc941f
Removing intermediate container 0d5aa7d28ca1
Step 2 : RUN npm config set proxy $HTTP_PROXY
 ---> Running in 98a09526b5d4
 ---> 937d442b3d42
Removing intermediate container 98a09526b5d4
Step 3 : COPY package.json /tmp/package.json
 ---> 3f7ca0058762
Removing intermediate container ebc82497c3c1
Step 4 : RUN cd /tmp && npm install
 ---> Running in b1981597b5dd
npm WARN deprecated gulp-clean@0.3.1: use gulp-rimraf instead
npm ERR! git clone --template=/root/.npm/_git-remotes/_templates --mirror git://github.com/benweet/gulp-inject.git /root/.npm/_git-remotes/git-github-com-benweet-gulp-inject-git-e1282b7e: Cloning into bare repository '/root/.npm/_git-remotes/git-github-com-benweet-gulp-inject-git-e1282b7e'...
npm ERR! git clone --template=/root/.npm/_git-remotes/_templates --mirror git://github.com/benweet/gulp-inject.git /root/.npm/_git-remotes/git-github-com-benweet-gulp-inject-git-e1282b7e: fatal: unable to connect to github.com:
npm ERR! git clone --template=/root/.npm/_git-remotes/_templates --mirror git://github.com/benweet/gulp-inject.git /root/.npm/_git-remotes/git-github-com-benweet-gulp-inject-git-e1282b7e: github.com[0: 192.30.252.128]: errno=Connection timed out
npm ERR! Linux 3.10.0-229.4.2.el7.x86_64
npm ERR! argv "node" "/usr/local/bin/npm" "install"
npm ERR! node v0.12.5
npm ERR! npm  v2.11.3
npm ERR! code 128
The command '/bin/sh -c cd /tmp && npm install' returned a non-zero code: 1

At first gland it looks like it works... But my host is behind the firewall, and I can only go out through the HTTP_PROXY... So, I might have something weird configured...

So, the design of the Dockerfile might also influence on this... Some systems like NPM require us to issue a command to setup the registry... http://jjasonclark.com/how-to-setup-node-behind-web-proxy/

As there is NO way to conditionally execute Dockerfile instruction during build, how could we address that @mapuri ???

# Pull base image.
FROM node:0.12

RUN echo $HTTP_PROXY
# Should only run when the environment has it set (ONLY RUN IF $HTTP_PROXY was provided) 
RUN npm config set proxy $HTTP_PROXY

COPY package.json /tmp/package.json

RUN cd /tmp && npm install

# Node base will default the command to `node server.js`.

# Expose port.
EXPOSE 3000
@mapuri

This comment has been minimized.

Show comment
Hide comment
@mapuri

mapuri Jul 4, 2015

Contributor

As there is NO way to conditionally execute Dockerfile instruction during build, how could we address that @mapuri ???

Following shall work to execute commands conditionally, in absence of a Dockerfile native conditional primitive. It does create a intermediate container but I think has same effect as you are looking for. WDYT?

RUN if [ "$HTTP_PROXY" != "" ]; then npm config set proxy $HTTP_PROXY; fi

Contributor

mapuri commented Jul 4, 2015

As there is NO way to conditionally execute Dockerfile instruction during build, how could we address that @mapuri ???

Following shall work to execute commands conditionally, in absence of a Dockerfile native conditional primitive. It does create a intermediate container but I think has same effect as you are looking for. WDYT?

RUN if [ "$HTTP_PROXY" != "" ]; then npm config set proxy $HTTP_PROXY; fi

@marcellodesales

This comment has been minimized.

Show comment
Hide comment
@marcellodesales

marcellodesales Jul 5, 2015

@mapuri Good News! It worked! It has been a long time since I've been attempting to build from those Cloud hosts and wow, this is the first time!!! I was building images locally on my desktop and pushing to our internal Registry.

Problem solved!

The problem I encountered in regards to github connectivity was related to Node.js' npm settings angular/angular-phonecat#141 (comment)... It was trying to git clone with the "git://" protocol... So, here's the updated Dockerfile as a reference for others to try:

# Pull base image.
FROM node:0.12

RUN echo $HTTP_PROXY
RUN npm config set proxy $HTTP_PROXY && git config --global url."https://".insteadOf git://

COPY package.json /tmp/package.json

RUN if [ "$HTTP_PROXY" != "" ]; then npm config set proxy $HTTP_PROXY && npm config list; fi

RUN cd /tmp && npm install -d

# Node base will default the command to `node server.js`.

# Expose port.
EXPOSE 3000

Docker build output

I grabbed my $HTTP_PROXY settings from the environment so the execution below assumes they are set. From what I can say, this approach is acceptable in the client point of view... Just like any other parameter to run, build also calls for this feature in as a natural requirement of builds in isolated environments.

The output of building the Dockerfile above is as follows:

# root at pppdc9prd8wu in /tmp/stackedit on git:master x [15:42:12]
$ docker build --no-cache=true --build-env http_proxy=$http_proxy --build-env https_proxy=$https_proxy --build-env no_proxy=$no_proxy --build-env HTTP_PROXY=$HTTP_PROXY --build-env HTTPS_PROXY=$HTTPS_PROXY --build-env NO_PROXY=$NO_PROXY .
Sending build context to Docker daemon 40.85 MB
Step 0 : FROM node:0.12
 ---> 20a32f7a591c
Step 1 : RUN echo $HTTP_PROXY
 ---> Running in f39030818bf2
http://qypprdproxy02.ie.intuit.net:80
 ---> 70176cd82684
Removing intermediate container f39030818bf2
Step 2 : RUN npm config set proxy $HTTP_PROXY && git config --global url."https://".insteadOf git://
 ---> Running in 4ccb1450c407
 ---> bbe373ebf241
Removing intermediate container 4ccb1450c407
Step 3 : COPY package.json /tmp/package.json
 ---> cc7f700a0a7b
Removing intermediate container c6889dcb7095
Step 4 : RUN if [ "$HTTP_PROXY" != "" ]; then npm config set proxy $HTTP_PROXY && npm config list; fi
 ---> Running in 7ddb2bfa909a
; cli configs
user-agent = "npm/2.11.3 node/v0.12.5 linux x64"

; userconfig /root/.npmrc
proxy = "http://qypprdproxy02.ie.intuit.net:80/"

; node bin location = /usr/local/bin/node
; cwd = /
; HOME = /root
; 'npm config ls -l' to show all defaults.

 ---> 0baab9052e6b
Removing intermediate container 7ddb2bfa909a
Step 5 : RUN cd /tmp && npm install -d
 ---> Running in 162ef5dc781a
npm info it worked if it ends with ok
npm info using npm@2.11.3
npm info using node@v0.12.5
npm info preinstall stackedit@4.3.11
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/request
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/ssh2
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/compression
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/serve-static
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/gulp
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/gulp-requirejs
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/gulp-jshint
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/gulp-uglify
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/gulp-less
npm info attempt registry request try #1 at 3:42:34 PM
npm info retry fetch attempt 1 at 3:42:36 PM
npm info attempt registry request try #1 at 3:42:36 PM
npm http fetch GET https://registry.npmjs.org/send/-/send-0.13.0.tgz
npm http 200 https://registry.npmjs.org/nopt
npm info build /tmp/node_modules/mime
npm info preinstall gulp-requirejs@0.1.3
npm http 200 https://registry.npmjs.org/update-notifier
npm http 200 https://registry.npmjs.org/minimatch
npm http fetch 200 https://registry.npmjs.org/escape-html/-/escape-html-1.0.2.tgz
npm http fetch 200 https://registry.npmjs.org/on-headers/-/on-headers-1.0.0.tgz
npm http 200 https://registry.npmjs.org/lodash._reescape
npm info attempt registry request try #1 at 3:42:36 PM
npm http request GET https://registry.npmjs.org/orchestrator
npm info attempt registry request try #1 at 3:42:36 PM
npm http request GET https://registry.npmjs.org/pretty-hrtime
npm info attempt registry request try #1 at 3:42:36 PM
npm http request GET https://registry.npmjs.org/semver
npm info attempt registry request try #1 at 3:42:36 PM
npm http request GET https://registry.npmjs.org/tildify
npm info attempt registry request try #1 at 3:42:36 PM
npm http request GET https://registry.npmjs.org/v8flags
...
...
...
└── inquirer@0.8.0 (ansi-regex@1.1.1, figures@1.3.5, mute-stream@0.0.4, through@2.3.8, readline2@0.1.1, chalk@0.5.1, lodash@2.4.2, cli-color@0.3.3, rx@2.5.3)

bower-requirejs@1.1.3 node_modules/bower-requirejs
├── slash@1.0.0
├── object-assign@2.1.1
├── sudo-block@1.2.0 (is-root@1.0.0, is-docker@1.0.0)
├── chalk@1.1.0 (escape-string-regexp@1.0.3, supports-color@2.0.0, ansi-styles@2.1.0, has-ansi@2.0.0, strip-ansi@3.0.0)
├── nopt@3.0.3 (abbrev@1.0.7)
├── requirejs@2.1.18
├── file-utils@0.2.2 (isbinaryfile@2.0.4, rimraf@2.4.1, glob@4.5.3, minimatch@2.0.8, findup-sync@0.2.1, iconv-lite@0.4.11, lodash@2.4.2)
├── update-notifier@0.3.2 (is-npm@1.0.0, string-length@1.0.0, semver-diff@2.0.0, latest-version@1.0.1, configstore@0.3.2)
└── lodash@3.10.0

gulp-less@1.3.9 node_modules/gulp-less
├── convert-source-map@0.4.1
├── lodash.defaults@2.4.1 (lodash._objecttypes@2.4.1, lodash.keys@2.4.1)
├── through2@0.5.1 (xtend@3.0.0, readable-stream@1.0.33)
├── vinyl-sourcemaps-apply@0.1.4 (source-map@0.1.43)
└── less@1.7.5 (graceful-fs@3.0.8, mime@1.2.11, source-map@0.1.43, mkdirp@0.5.1, clean-css@2.2.23)
npm info ok
 ---> a261278405d8
Removing intermediate container 162ef5dc781a
Step 6 : EXPOSE 3000
 ---> Running in 463e0c82ae28
 ---> 2773a577834c
Removing intermediate container 463e0c82ae28
Successfully built 2773a577834c

Follow up Questions

@mapuri, the trick with conditions makes me feel we need to address the case either having a conditional instruction or something else. What I'm thinking here is that there could be potentially 2 different images built:

  • One from building on an environment with HTTP_PROXY
  • One from building without

So, It looks like there are implications on the idempotency of the resulting images on the 2 scenarios... Those settings that I just set were performed for the sake of making the build pass. However, they could potentially affect the normal execution of the container, given the changes.

Has anyone discussed disposable layers? What if I wanna run a conditional Instruction and have it removed in the final Image? Say...

RUN {throwAway, conditional ($HTTP_PROXY != "")} npm config set proxy $HTTP_PROXY

marcellodesales commented Jul 5, 2015

@mapuri Good News! It worked! It has been a long time since I've been attempting to build from those Cloud hosts and wow, this is the first time!!! I was building images locally on my desktop and pushing to our internal Registry.

Problem solved!

The problem I encountered in regards to github connectivity was related to Node.js' npm settings angular/angular-phonecat#141 (comment)... It was trying to git clone with the "git://" protocol... So, here's the updated Dockerfile as a reference for others to try:

# Pull base image.
FROM node:0.12

RUN echo $HTTP_PROXY
RUN npm config set proxy $HTTP_PROXY && git config --global url."https://".insteadOf git://

COPY package.json /tmp/package.json

RUN if [ "$HTTP_PROXY" != "" ]; then npm config set proxy $HTTP_PROXY && npm config list; fi

RUN cd /tmp && npm install -d

# Node base will default the command to `node server.js`.

# Expose port.
EXPOSE 3000

Docker build output

I grabbed my $HTTP_PROXY settings from the environment so the execution below assumes they are set. From what I can say, this approach is acceptable in the client point of view... Just like any other parameter to run, build also calls for this feature in as a natural requirement of builds in isolated environments.

The output of building the Dockerfile above is as follows:

# root at pppdc9prd8wu in /tmp/stackedit on git:master x [15:42:12]
$ docker build --no-cache=true --build-env http_proxy=$http_proxy --build-env https_proxy=$https_proxy --build-env no_proxy=$no_proxy --build-env HTTP_PROXY=$HTTP_PROXY --build-env HTTPS_PROXY=$HTTPS_PROXY --build-env NO_PROXY=$NO_PROXY .
Sending build context to Docker daemon 40.85 MB
Step 0 : FROM node:0.12
 ---> 20a32f7a591c
Step 1 : RUN echo $HTTP_PROXY
 ---> Running in f39030818bf2
http://qypprdproxy02.ie.intuit.net:80
 ---> 70176cd82684
Removing intermediate container f39030818bf2
Step 2 : RUN npm config set proxy $HTTP_PROXY && git config --global url."https://".insteadOf git://
 ---> Running in 4ccb1450c407
 ---> bbe373ebf241
Removing intermediate container 4ccb1450c407
Step 3 : COPY package.json /tmp/package.json
 ---> cc7f700a0a7b
Removing intermediate container c6889dcb7095
Step 4 : RUN if [ "$HTTP_PROXY" != "" ]; then npm config set proxy $HTTP_PROXY && npm config list; fi
 ---> Running in 7ddb2bfa909a
; cli configs
user-agent = "npm/2.11.3 node/v0.12.5 linux x64"

; userconfig /root/.npmrc
proxy = "http://qypprdproxy02.ie.intuit.net:80/"

; node bin location = /usr/local/bin/node
; cwd = /
; HOME = /root
; 'npm config ls -l' to show all defaults.

 ---> 0baab9052e6b
Removing intermediate container 7ddb2bfa909a
Step 5 : RUN cd /tmp && npm install -d
 ---> Running in 162ef5dc781a
npm info it worked if it ends with ok
npm info using npm@2.11.3
npm info using node@v0.12.5
npm info preinstall stackedit@4.3.11
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/request
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/ssh2
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/compression
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/serve-static
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/gulp
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/gulp-requirejs
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/gulp-jshint
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/gulp-uglify
npm info attempt registry request try #1 at 3:42:34 PM
npm http request GET https://registry.npmjs.org/gulp-less
npm info attempt registry request try #1 at 3:42:34 PM
npm info retry fetch attempt 1 at 3:42:36 PM
npm info attempt registry request try #1 at 3:42:36 PM
npm http fetch GET https://registry.npmjs.org/send/-/send-0.13.0.tgz
npm http 200 https://registry.npmjs.org/nopt
npm info build /tmp/node_modules/mime
npm info preinstall gulp-requirejs@0.1.3
npm http 200 https://registry.npmjs.org/update-notifier
npm http 200 https://registry.npmjs.org/minimatch
npm http fetch 200 https://registry.npmjs.org/escape-html/-/escape-html-1.0.2.tgz
npm http fetch 200 https://registry.npmjs.org/on-headers/-/on-headers-1.0.0.tgz
npm http 200 https://registry.npmjs.org/lodash._reescape
npm info attempt registry request try #1 at 3:42:36 PM
npm http request GET https://registry.npmjs.org/orchestrator
npm info attempt registry request try #1 at 3:42:36 PM
npm http request GET https://registry.npmjs.org/pretty-hrtime
npm info attempt registry request try #1 at 3:42:36 PM
npm http request GET https://registry.npmjs.org/semver
npm info attempt registry request try #1 at 3:42:36 PM
npm http request GET https://registry.npmjs.org/tildify
npm info attempt registry request try #1 at 3:42:36 PM
npm http request GET https://registry.npmjs.org/v8flags
...
...
...
└── inquirer@0.8.0 (ansi-regex@1.1.1, figures@1.3.5, mute-stream@0.0.4, through@2.3.8, readline2@0.1.1, chalk@0.5.1, lodash@2.4.2, cli-color@0.3.3, rx@2.5.3)

bower-requirejs@1.1.3 node_modules/bower-requirejs
├── slash@1.0.0
├── object-assign@2.1.1
├── sudo-block@1.2.0 (is-root@1.0.0, is-docker@1.0.0)
├── chalk@1.1.0 (escape-string-regexp@1.0.3, supports-color@2.0.0, ansi-styles@2.1.0, has-ansi@2.0.0, strip-ansi@3.0.0)
├── nopt@3.0.3 (abbrev@1.0.7)
├── requirejs@2.1.18
├── file-utils@0.2.2 (isbinaryfile@2.0.4, rimraf@2.4.1, glob@4.5.3, minimatch@2.0.8, findup-sync@0.2.1, iconv-lite@0.4.11, lodash@2.4.2)
├── update-notifier@0.3.2 (is-npm@1.0.0, string-length@1.0.0, semver-diff@2.0.0, latest-version@1.0.1, configstore@0.3.2)
└── lodash@3.10.0

gulp-less@1.3.9 node_modules/gulp-less
├── convert-source-map@0.4.1
├── lodash.defaults@2.4.1 (lodash._objecttypes@2.4.1, lodash.keys@2.4.1)
├── through2@0.5.1 (xtend@3.0.0, readable-stream@1.0.33)
├── vinyl-sourcemaps-apply@0.1.4 (source-map@0.1.43)
└── less@1.7.5 (graceful-fs@3.0.8, mime@1.2.11, source-map@0.1.43, mkdirp@0.5.1, clean-css@2.2.23)
npm info ok
 ---> a261278405d8
Removing intermediate container 162ef5dc781a
Step 6 : EXPOSE 3000
 ---> Running in 463e0c82ae28
 ---> 2773a577834c
Removing intermediate container 463e0c82ae28
Successfully built 2773a577834c

Follow up Questions

@mapuri, the trick with conditions makes me feel we need to address the case either having a conditional instruction or something else. What I'm thinking here is that there could be potentially 2 different images built:

  • One from building on an environment with HTTP_PROXY
  • One from building without

So, It looks like there are implications on the idempotency of the resulting images on the 2 scenarios... Those settings that I just set were performed for the sake of making the build pass. However, they could potentially affect the normal execution of the container, given the changes.

Has anyone discussed disposable layers? What if I wanna run a conditional Instruction and have it removed in the final Image? Say...

RUN {throwAway, conditional ($HTTP_PROXY != "")} npm config set proxy $HTTP_PROXY
@mapuri

This comment has been minimized.

Show comment
Hide comment
@mapuri

mapuri Jul 5, 2015

Contributor

@marcellodesales

Good to know this worked for you!

Has anyone discussed disposable layers? What if I wanna run a conditional Instruction and have it removed in the final Image?
RUN {throwAway, conditional ($HTTP_PROXY != "")} npm config set proxy $HTTP_PROXY

Having the command-line variables available for use in Dockerfile does enable the usecase of parameterized builds as mentioned in some of the comments elsewhere in this PR. I think conditionals in a form that you mentioned shall fall in a similar category. However, I am not sure if there is any open PR or issue for the same.

Contributor

mapuri commented Jul 5, 2015

@marcellodesales

Good to know this worked for you!

Has anyone discussed disposable layers? What if I wanna run a conditional Instruction and have it removed in the final Image?
RUN {throwAway, conditional ($HTTP_PROXY != "")} npm config set proxy $HTTP_PROXY

Having the command-line variables available for use in Dockerfile does enable the usecase of parameterized builds as mentioned in some of the comments elsewhere in this PR. I think conditionals in a form that you mentioned shall fall in a similar category. However, I am not sure if there is any open PR or issue for the same.

@flaccid

This comment has been minimized.

Show comment
Hide comment
@flaccid

flaccid Jul 9, 2015

Contributor

In addition to the proxy use case, I have one other.

I would like to set tags (TAG) in my Dockerfile for metadata such as the build date. Essentially there are valid uses cases for setting tags in a Dockerfile that are dynamic and change every build, particularly in a CI/CD pipeline, having -e would help. This could also be solved by allowing interpolation within the Dockerfile (I'm pretty sure there is at least one issue open for this) e.g. shelling out to the data command.

Currently at the moment I have to copy the Dockerfile to say Dockerfile.build which is temporary and do a sed replace on a couple of placeholder strings, then build with -f Dockerfile.build.

Contributor

flaccid commented Jul 9, 2015

In addition to the proxy use case, I have one other.

I would like to set tags (TAG) in my Dockerfile for metadata such as the build date. Essentially there are valid uses cases for setting tags in a Dockerfile that are dynamic and change every build, particularly in a CI/CD pipeline, having -e would help. This could also be solved by allowing interpolation within the Dockerfile (I'm pretty sure there is at least one issue open for this) e.g. shelling out to the data command.

Currently at the moment I have to copy the Dockerfile to say Dockerfile.build which is temporary and do a sed replace on a couple of placeholder strings, then build with -f Dockerfile.build.

@youngl98

This comment has been minimized.

Show comment
Hide comment
@youngl98

youngl98 Jul 11, 2015

  • 1, I am glad that environment passing is happening in docker build. I been hardcoding the http_proxy in all the internal Dockerfiles...

youngl98 commented Jul 11, 2015

  • 1, I am glad that environment passing is happening in docker build. I been hardcoding the http_proxy in all the internal Dockerfiles...
@andrewshawcare

This comment has been minimized.

Show comment
Hide comment
@andrewshawcare

andrewshawcare Jul 12, 2015

+1, I don't see a better option to pass in extraneous build information without making one-off conventions that ultimately expose environment data.

Example: Datomic requires each user to authenticate in order to download the datomic zip. This means the datomic image needs a username and password injected on build somehow. You could use a .docker-datomic-credentials file, but then you have to know to populate a .docker-datomic-credentials file (or something else). That is unintuitive (a bunch of files, like .docker-proxy, that all are only relevant for exposing environment variables to docker and nobody knows that unless they read the Dockerfile or parent image Dockerfile).

Eventually it seems you would want a convention like docker-onbuild.environment to somewhat address the intuitiveness concern, which means adding your own COPY onbuild.environment /tmp/docker-onbuild.environment, RUN . /tmp/docker-onbuild.environment && ... and RUN rm /tmp/docker-onbuild.environment commands to expose those environment variables only on container builds.

Then you realize it would be nice to include this file as an argument so you don't have to worry about missing the rm at the end of your Dockerfiles (and not have to source the variables on every RUN). That leads to the ability to have a docker build --env-file onbuild.environment . or docker-build --env "FOO=bar" ..

andrewshawcare commented Jul 12, 2015

+1, I don't see a better option to pass in extraneous build information without making one-off conventions that ultimately expose environment data.

Example: Datomic requires each user to authenticate in order to download the datomic zip. This means the datomic image needs a username and password injected on build somehow. You could use a .docker-datomic-credentials file, but then you have to know to populate a .docker-datomic-credentials file (or something else). That is unintuitive (a bunch of files, like .docker-proxy, that all are only relevant for exposing environment variables to docker and nobody knows that unless they read the Dockerfile or parent image Dockerfile).

Eventually it seems you would want a convention like docker-onbuild.environment to somewhat address the intuitiveness concern, which means adding your own COPY onbuild.environment /tmp/docker-onbuild.environment, RUN . /tmp/docker-onbuild.environment && ... and RUN rm /tmp/docker-onbuild.environment commands to expose those environment variables only on container builds.

Then you realize it would be nice to include this file as an argument so you don't have to worry about missing the rm at the end of your Dockerfiles (and not have to source the variables on every RUN). That leads to the ability to have a docker build --env-file onbuild.environment . or docker-build --env "FOO=bar" ..

@stuarthannig

This comment has been minimized.

Show comment
Hide comment
@stuarthannig

stuarthannig Jul 18, 2015

+1

I'm in much need of this feature to support privately forked repositories.

stuarthannig commented Jul 18, 2015

+1

I'm in much need of this feature to support privately forked repositories.

@fortitudecloud

This comment has been minimized.

Show comment
Hide comment
@fortitudecloud

fortitudecloud Jul 21, 2015

+1
This would greatly simplify my already generic build process

fortitudecloud commented Jul 21, 2015

+1
This would greatly simplify my already generic build process

@vlad-belogrudov

This comment has been minimized.

Show comment
Hide comment
@vlad-belogrudov

vlad-belogrudov Jul 21, 2015

+1
long awaited options!

vlad-belogrudov commented Jul 21, 2015

+1
long awaited options!

@brk3

This comment has been minimized.

Show comment
Hide comment
@brk3

brk3 commented Jul 23, 2015

+1

@theothermattm

This comment has been minimized.

Show comment
Hide comment

theothermattm commented Jul 23, 2015

+1

Add support for passing build-time environment variables in build con…
…text

- The build-time environment variables are passed as environment-context for command(s)
run as part of the RUN primitve. These variables are not persisted in environment of
intermediate and final images when passed as context for RUN. The build environment
is prepended to the intermediate continer's command string for aiding cache lookups.
It also helps with build traceability. But this also makes the feature less secure from
point of view of passing build time secrets.

- The build-time environment variables also get used to expand the symbols used in certain
Dockerfile primitves like ADD, COPY, USER etc, without an explicit prior definiton using a
ENV primitive. These variables get persisted in the intermediate and final images
whenever they are expanded.

Signed-off-by: Madhav Puri <madhav.puri@gmail.com>
@nathanboktae

This comment has been minimized.

Show comment
Hide comment
@nathanboktae

nathanboktae Jul 23, 2015

+1 the Docker build is totally dependent on the state of the files it's working with, so if those files weren't placed predictably then the build will result in a different output. That argument is a strawman.

Many, many users including myself are using hacks to pipe in information into the build process... we need this PR.

nathanboktae commented Jul 23, 2015

+1 the Docker build is totally dependent on the state of the files it's working with, so if those files weren't placed predictably then the build will result in a different output. That argument is a strawman.

Many, many users including myself are using hacks to pipe in information into the build process... we need this PR.

@sebastiangraf

This comment has been minimized.

Show comment
Hide comment

sebastiangraf commented Jul 24, 2015

+1

@imasen

This comment has been minimized.

Show comment
Hide comment
@imasen

imasen commented Jul 24, 2015

+1

@AndyBerman

This comment has been minimized.

Show comment
Hide comment
@AndyBerman

AndyBerman commented Jul 24, 2015

+1

@baio

This comment has been minimized.

Show comment
Hide comment
@baio

baio commented Jul 24, 2015

+1

@icecrime

This comment has been minimized.

Show comment
Hide comment
@icecrime

icecrime Jul 24, 2015

Contributor

@mapuri The signal to noise ratio in this thread has reach a point where I just cannot keep up. Please come ping me on IRC or send me a mail, and we can discuss the way to move forward into a solution that we will merge. Thank you for your work and time.

Contributor

icecrime commented Jul 24, 2015

@mapuri The signal to noise ratio in this thread has reach a point where I just cannot keep up. Please come ping me on IRC or send me a mail, and we can discuss the way to move forward into a solution that we will merge. Thank you for your work and time.

@mapuri

This comment has been minimized.

Show comment
Hide comment
@mapuri

mapuri Jul 24, 2015

Contributor

Closing this in favor of #14634 .

I will work on adapting the changes in this PR to the spec detailed in #14634. Hoping to address the use cases that this thread brought up.

Contributor

mapuri commented Jul 24, 2015

Closing this in favor of #14634 .

I will work on adapting the changes in this PR to the spec detailed in #14634. Hoping to address the use cases that this thread brought up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment