Escaping template strings not working

[hnicke]

Bug

Current Behavior

I need the literal value ${foo} in a resulting k8s template of a garden kubernetes module.
The garden docs describe how this should be done: Using $${} instead of ${}.

...
command: [ bash ]
args:
  - c
  - |
    ....
    -d '$${foo}'

However, it ends up literally like this after rendering:

...
command: [ bash ]
args:
  - c
  - |
    ....
    -d '$${foo}'

I.e., no interpolation at all happened.

Garden doesn't eat the dollar. Maybe this only happens in the free tier 😆

Expected behavior

I expect this to be the result of the template rendering:

...
command: [ bash ]
args:
  - c
  - |
    ....
    -d '${foo}'

Additional idea

@worldofgeese pointed me to the docs, which I haven't found on my own.
I suggest moving the whole Escaping template strings paragraph from Module Templates to Variables and Templating. My understanding is that the Module Templates page only holds information in regards to the kind: Module; type: templated modules. The interpolation escape mechanism however is a globally available feature, right?

Your environment

• OS: arch linux
• How I'm running Kubernetes: GKE

garden version
v0.12.53

[orymate]

We've workarounded this by rearranging the manifest templates in a way that all variable substitutions come before the parts that need escaping, and adding a comment like # hack: $${} between the two. No variable substitutions are done in the second part of the manifest, at least in 0.12.60.

...
spec:
  loggingRef: ${environment.namespace}-demo  # TODO garden fails to expand this variable after the first escape, keeping this line before that
  # hack: $${}
  filters:
    - parser:
        metrics-probe:
          key: "probe"
          labels:
            namespace: "${json#kubernetes#namespace_name}"  # the manifests contain these exact label templates that use similar variable expansion syntax as garden
            pod: "${json#kubernetes#pod_name}"

[vvagaytsev]

@orymate thanks for sharing the workaround!

[vvagaytsev]

@orymate we have fixed this in 0.13.39. Feel free to try it out!

Please note, that the workaround cannot be used along with 0.13.39.