CODEWITHSUNDEEP
terraformgrafanagrafana-templating
user2886057
user2886057

Reputation: 735

terraform validate failing on generated file

I was wondering what the right approach is here. Im using jsonette to generate a dashboard json. When I run terraform validate I get the following error:

Invalid value for "path" parameter: no file exists at "../grafana/dashboards/gateway-single.rendered.json"; this
function works only with files that are distributed as part of the configuration source code, so if this file will be
created by a resource in this configuration you must instead obtain this result from an attribute of that resource.

This is because the file doesn't exist on disk. I can think of a couple of different ways to hack around this, or just forcing the compilation to happen before validate in CI. But Im wondering here what the right pattern for generated files in terraform.

Upvotes: 0

Views: 76

Answers (1)

Martin Atkins
Martin Atkins

Reputation: 74084

Although it's best to avoid making Terraform configurations modify the local filesystem during their operation, since that tends to lead to a configuration that's hard to run in a variety of different contexts, there is an "escape hatch" for interacting with the local filesystem using the hashicorp/local provider.

That provider offers two main building blocks that could potentially help with your problem:

  • The local_file data source allows treating a file on disk as a dynamic data source, participating in Terraform's dependency graph in the usual way for data resources.

    That means that, for example, it could depend on another resource that's arranging for that file to be created, so that the read happens at the right time.

  • The local_file managed resource type allows managing a single file on disk in a similar way to how Terraform would typically manage objects in a remote API.

    That means that you can use Terraform to create and update a file in the local filesystem, based on data available in your Terraform configuration. Since it's used via a normal resource block, it participates in the plan/apply process and the dependency graph in a similar way to API-backed resource types.

The file function serves a different purpose: it's to deal with situations where the configuration makes use of other files distributed along with the configuration itself -- typically in the same version control system -- that are to be used as if they are part of the configuration itself, rather than one of the remote objects being retrieved or managed.

For example, it's possible to use file in conjunction with yamldecode in situations where teams find it more convienient to describe some part of their infrastructure in YAML and then translate that systematically into corresponding Terraform resource instances, but with the YAML treated as part of the same set of source code as the .tf files that refer to it.

Upvotes: -1

Related Questions