I have a terraform script that outputs a number of EKS related config files - previously this has worked exactly as expected - over the last week or two I’ve noticed a change which has sadly broken the scripts.
The outputs which use the heredoc syntax;
Have the <<EOT & EOT in the output files, has something changed I’ve missed in the release notes?
I tried running a reduced version of your configuration (with just the outputs) and the output values looked correct to me. Terraform included <<EOT and EOT in its rendering of the value because the output from Terraform is intended to be similar to the configuration syntax, but the actual value saved in the state was the final value without those markers.
In your question you mentioned “the output files”. I initially thought you meant outputs.tf, but I think you might actually be talking about something else. Can you explain more about what the output files are, and how you created them?
Absolutely - these scripts are run by a Jenkins file, which in turn calls a bash script.
This previously called terraform output kubeconfig > ./output/kubeconfig
Then export KUBECONFIG=./output/kubeconfig could be used (for example) to use the files.
But recently these files have had the <<EOT & EOT at top and bottom. Currently, to my shame, I pipe them through sed and remove them before usage, but it’s not clear to me what’s changed on my end to cause this, if anything at all.
Ahh, I see! Sorry I didn’t understand this earlier.
It looks like you were using the terraform output's default output to write to a file, but we considered that default output to be “human-oriented” output similar to what you see in terraform plan, rather than raw data intended to be read by other software.
You’ve already now learned about the -json option, which is indeed what I would’ve suggested as a way to get machine-oriented output instead of human-oriented output.
Sorry again that I didn’t understand what you were describing before. I hope this JSON-based solution works for addressing your problem.
Thanks for sharing that, @scardena. Indeed, in a later release (after my previous comment) we added the -raw option as an alternative to -json for situations where the output value is just a plan string, so that it’d be more convenient to use for situations like yours where you’re either writing the result directly to a file, or using it as part of a wrapper shell script for some other subsequent action.