score-spec / score-compose

Reference implementation for docker-compose target platform support
https://docs.score.dev/docs/score-implementation/score-compose/
Apache License 2.0
446 stars 42 forks source link

[bug] score-compose causes double $$ escapes to break #148

Open astromechza opened 4 months ago

astromechza commented 4 months ago

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.

astromechza commented 4 months ago

This will need changes in github.com/score-spec/score-go.

astromechza commented 3 months ago

I've cut https://github.com/score-spec/score-go/pull/42 to improve this in score-go