4 Commits (c6cbbcb79a751fcee2334b22bb3ee18aecaefb91)

Author	SHA1	Message	Date
Martin Atkins	67d95b97ce	lang/funcs: templatefile requires valid variable names ... Previously the templatefile function would permit any arbitrary string as a variable name, but due to the HCL template syntax it would be impossible to refer to one that isn't a valid HCL identifier without causing an HCL syntax error. The HCL syntax errors are correct, but don't really point to the root cause of the problem. Instead, we'll pre-verify that the variable names are valid before we even try to render the template, and given a specialized error message that refers to the vars argument expression as the problematic part, which will hopefully make the resolution path clearer for a user encountering this situation. The syntax error still remains for situations where all of the variable names are correct but e.g. the user made a typo referring to one, which makes sense because in that case the problem _is_ inside the template.	6 years ago
Martin Atkins	bfbd00a23c	website: Note about using jsonencode/yamlencode in templatefile ... It's a common source of errors to try to produce JSON or YAML syntax using string concatenation via our template language but to miss some details like correct string escaping, quoting, required commas, etc. The jsonencode and yamlencode functions are a better way to generate JSON and YAML, but it's not immediately obvious that both of these functions are available for use in external templates (via templatefile) too. Given that questions related to this come up a lot in our community forum and elsewhere, it seems worth having a documentation section to show the pattern of having a template that consists only of a single function call.	6 years ago
Nick Fagerlund	2c50808bbb	website: Version notes: Add new -> old links to 0.12 language docs (function pages)	7 years ago
Martin Atkins	c753df6a93	lang/funcs: templatefile function ... This function is similar to the template_file data source offered by the template provider, but having it built in to the language makes it more convenient to use, allowing templates to be rendered from files anywhere an inline template would normally be allowed: user_data = templatefile("${path.module}/userdata.tmpl", { hostname = format("petserver%02d", count.index) }) Unlike the template_file data source, this function allows values of any type in its variables map, passing them through verbatim to the template. Its tighter integration with Terraform also allows it to return better error messages with source location information from the template itself. The template_file data source was originally created to work around the fact that HIL didn't have any support for map values at the time, and even once map support was added it wasn't very usable. With HCL2 expressions, there's little reason left to use a data source to render a template; the only remaining reason left to use template_file is to render a template that is constructed dynamically during the Terraform run, which is a very rare need.	7 years ago