Terraform.tfvars - templating is not filled in

I included a terraform.tfvars file in my tfvars folder in a module, with multiple templating entries in it (i.e. expansion, aws_secrets, etc), and after running terraform build, in the resulting cache folder the file is copied exactly as is (with the templating syntax) into terraform.tfvars inside the module in .terraspace-cache.

Is somehow this filename protected and therefore the templating will not be run? Any help would be great!

Thanks!

UPDATE 25.6: I noticed that here you mention that only rb and tf files are processed - however we do see substitution in .tfvars files, not only in .tf files. I guess my main question is exactly which files are processed for expressions and which are not.

Fixed in https://github.com/boltops-tools/terraspace/pull/159
Also updated the docs: https://terraspace.cloud/docs/config/pass-files/

Hi Tung,

One slightly related question… The pass files strategy allows files to be copied straight to the build cache without any processing. But is there a way to include the erb templating against files that does not end with .tf , .tfvars and .rb ? E.g. is there a way to include erb templating on e.g. .json file or .sh file?

Many thanks,
James

Interesting. Not yet. Some thoughts:

  1. Make the default fallback strategy be ERB instead of Pass. Currently, it is Pass. For a very small period of time, about 2 days, had changed the default strategy to ERB, but reverted it after running into some issues that had not been considered like binary files. Yes, folks put binary zip files in their terraform form code. :rofl: Typically as part of packaging a lambda function. Can possibly make the default fallback processing strategy configurable with config.build.default_strategy and add it to the docs: https://terraspace.cloud/docs/config/reference/

Here’s the PR that reverted the ERB as the default strategy:

  1. Another idea that comes mind is to add support for processing any file with the .erb extension. The .erb ext would be removed from the final compiled file in .terraspace-cache. So:

    file.json.erb -> file.json
    script.sh.erb -> script.sh

Am leaning on #1 with the config. And keep backwards compatibility for older terraspace projects. Newer terraspace projects will have config.build.default_strategy = "erb" when folks use the terraspace new project generator.

Unsure though. Will have to let it simmer. :face_with_monocle:

1 Like

@tung
Was this templating for standard non HCL files ever implemented?

I am trying to generate some dynamic configuration files using the ERB/TS templating for a specific stack deployment.
I have tried using putting some files in config/stacks/<STACK>/tfvars/ like cfg_file.json.erb just they are not processed.

The mix of idea 2 could be great, as it would allow putting any files even binaries in the folder pass_files and if we need some extra templating power just add the extra extension .erb and it would be processed and the extra extension removed.

Not yet. Thinking would render either .tt or .erb extension. IE: cfg_file.json.tt or cfg_file.json.erb.

Unsure exactly when will get to it. Will review and consider PRs. Of course no sweat either way :+1: Thanks!

Effectively the actual extension name is not that important, tt = Text Template sounds like a catchy name :wink:

As we talked having a generic templating engine is the missing piece in all these kind of tools

Yup :+1: Notice the .tt used by Thor as well as a few other libraries. It’s nice looking.

Hello,

I am looking for a simple way of replacing some simple external configuration files with the deployment values.
Is there a way of passing or getting the full context of the defined tfvars in a hook?

Before running the terraform I need some configuration files to be changed with the stack defined variables.
This could be a simple workaround until there is a full templating solution.

class ShowContext
  def call(runner)
    # Get the defined tfvars values of the executed stack
  end
end

after("build",
  label: "ShowContext",
  execute: ShowContext,
  exit_on_fail: true
)