You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: