When a variable contains $${foo} we current unescape it to ${foo} in the Dockerfile, which then causes the compose execution to break if the variable foo is not available, or if the format is bad like ${foo.bar.baz}.
This is generally not what we expect, and we'd rather users use an environment type resource if they need to access environment variables. Thus we want ${foo} to be escaped again, back to $${foo}, OR to add some other mechanism for resolving these.
A big usecase is for something like a workload that has $${pod.metadata.name} in an environment variable because the end goal is to deploy to Humanitec. Docker will never resolve ${pod.metadata.name}. And overrides are not useful here, because they must be applied to the whole usage of the variable, not the actual placeholder itself.
Solution 1: Do nothing, customers must find and replace the unsatisified placeholders before running compose up.
Solution 2: Replace $${foo.bar} with ${FOO_BAR} so that an environment variable can be used.
Solution 3: Don't unescape $${foo.bar} in variables, so that it just stays as ${foo.bar} at runtime.
Solution 4: Provide a --override-placeholder foo.bar=new-value option to supply a value to replace.
Solution 5. A mix of 3, and 4.
So far I think solution 5 is the answer: default to no escape, but allow override.
When a variable contains
$${foo}
we current unescape it to${foo}
in the Dockerfile, which then causes the compose execution to break if the variable foo is not available, or if the format is bad like${foo.bar.baz}
.This is generally not what we expect, and we'd rather users use an
environment
type resource if they need to access environment variables. Thus we want${foo}
to be escaped again, back to$${foo}
, OR to add some other mechanism for resolving these.A big usecase is for something like a workload that has
$${pod.metadata.name}
in an environment variable because the end goal is to deploy to Humanitec. Docker will never resolve${pod.metadata.name}
. And overrides are not useful here, because they must be applied to the whole usage of the variable, not the actual placeholder itself.Solution 1: Do nothing, customers must find and replace the unsatisified placeholders before running
compose up
.Solution 2: Replace
$${foo.bar}
with${FOO_BAR}
so that an environment variable can be used.Solution 3: Don't unescape
$${foo.bar}
in variables, so that it just stays as${foo.bar}
at runtime.Solution 4: Provide a
--override-placeholder foo.bar=new-value option
to supply a value to replace.Solution 5. A mix of 3, and 4.
So far I think solution 5 is the answer: default to no escape, but allow override.