TerraformVariable of number type doesn't get replaced

[shishkin]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

cdktf & Language Versions

cdktf 0.14.1 with TypeScript

UPDATE: Same behavior in 0.14.3.

Affected Provider / Resource(s)

@cdktf/provider-kubernetes

Tried on ConfigMapV1 and SecretV1

Debug Output

https://gist.github.com/shishkin/1c6b19a7e1c6fb92f2734a694c7b3013#file-output

Expected Behavior

Expected the clusterPortHttps variable replaced with its value in the resulting config map resource.

Actual Behavior

var.CLUSTER_PORT_HTTPS is output inside resulting config map resource.

Steps to Reproduce

https://gist.github.com/shishkin/1c6b19a7e1c6fb92f2734a694c7b3013#file-stack-ts

Important Factoids

Numeric variable value is output correctly when put inside TerraformOutput construct. String variable clusterDomain is output correctly inside both config map resource and TerraformOutput.

UPDATE: Also the port number is output in the config map resource correctly when its value is referred to via .stringValue or .value instead of typed .numberValue.

References

[ansgarm]

Hi @shishkin 👋

This seems weird. Would you mind sharing the cdk.tf.json file that is generated in the cdktf.out/<your stack> directory? I'm curious what the interpolated string looks like in there.

[shishkin]

@ansgarm I've put it in the gist: https://gist.github.com/shishkin/1c6b19a7e1c6fb92f2734a694c7b3013#file-cdk-tf-json-L36

Indeed, the string interpolation syntax seems missing for the numeric variable:

"data": {
  "config": "${yamlencode({url = \"https://${var.CLUSTER_DOMAIN}:var.CLUSTER_PORT_HTTPS/\"})}"
},

[ansgarm]

Yup, seems like a bug on our end 👍 Thanks for reporting!

As using variable.stringValue works as a workaround, it is luckily not that pressing but still something we need to tackle 🐛