Arg blank string defaulting overrides docker default build arg values

[srhb]

If several services in a composition contain the same build arg, it's very hard (I haven't found a good method yet) to disambiguate it while retaining the ability to have default build args in a Dockerfile.

The obvious way to disambiguate build args would be to prepend the service name:

a:
  build:
    args:
      - x=$a_x
b:
  build:
    args:
      - x=$b_x

However, if $a_x or $b_x are unset, they will be defaulted to empty strings with the warning:

WARNING: The a_x variable is not set. Defaulting to a blank string.

Now, they will be passed to docker build as empty strings, circumventing any default arg in the Dockerfile.

This seems to me to be a very surprising and not docker-like way of handling it. A less surprising (and more featureful) method would be to not pass unset build args at all.

[srhb]

I just realized I've been testing this against 1.6.2 by mistake. Apologies if it does not apply anymore. I will retest with 1.7.1 as soon as possible.

[srhb]

The issue persists in 1.7.1.

Moreover, both 1.6.2 and 1.7.1 produces "None" as the arg value if the arg is specified as

a:
  build:
    - x

or

a:
  build:
    x:

[shin-]

That second issue you mention is also reported in #3281 and will be fixed by #3449
As for the original post, I'm not sure I understand what the question / issue is. Do you mind clarifying?

[srhb]

Thanks! And sure, I'll try.

Consider a Dockerfile which has:

ARG x=1

That is, it has a parameterized build argument "x", which will default to 1 if no --build-arg x=... is given

However, if we wish to parameterize our compose file in a similar fashion as in the examples above, we are left with no option. As soon as we specify a build arg in the compose file, we cannot recover the default from the Dockerfile at build time, as an unset var in - x=$x will always at least be the empty string and never count as not setting --build-arg x=...

This in turn seems to make it impossible to disambiguate a build arg with the same name (from two or more separate Dockerfiles, or even the same, built with different values) in a composition if we ever want one of the services to rely on the default value specified in the Dockerfile.

[shin-]

Oh, that makes a lot of sense - thanks for taking the time to clarify.
Maybe we need a special notation to say "Use the default value from the Dockerfile".

[srhb]

Or rather "if this environment variable is undefined, use the default value from the Dockerfile"

Otherwise parameterization would still fail. :-)

Thanks!

[shin-]

That might break existing applications that rely on the way things currently work, hence "maybe". I'm not sure how much of a concern that is. @aanand @dnephin Thoughts?

[srhb]

Even if the notation is new and unique?
On Jun 1, 2016 20:43, "Joffrey F" notifications@github.com wrote:

That might break existing applications that rely on the way things
currently work, hence "maybe". I'm not sure how much of a concern that is.
@aanand https://github.com/aanand @dnephin https://github.com/dnephin
Thoughts?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#3533 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AANY4qUPXiMk-5_e2tI4TkEbw_P7D2Ggks5qHdLSgaJpZM4Iqlo0
.

[dnephin]

Moreover, both 1.6.2 and 1.7.1 produces "None" as the arg value if the arg is specified as

I believe we fixed this bug in master, so the fix will be in 1.8.0. I think using the "no value" style is the correct way to handle this: args: x=