Expose current version to terraform object

[garthkerr]

Current Terraform Version

Terraform v0.12.6

Use-cases

There are some case where we might want to keep track of the version of terraform that a resource was provisioned with, beyond state.

Attempted Solutions

Of course, this could be accomplished a number of ways with an environment variable, but having access as a built-in variable would help standardize access to this information.

Proposal

From HCL, we should be able to access an attribute containing the current runtime version terraform.verson in the same manner that we can currently access the terraform.workspace attribute with global context.

output "terraform_version" {
  value = terraform.version
}

$ terraform apply

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:
terraform_version = 0.12.6

[teamterraform]

Hi @garthkerr! Thanks for sharing this use-case.

If you'd be willing, we'd like to capture here a little more detail about what higher-level problem you're trying to solve by capturing the Terraform version.

A particular thing we're thinking about is that Terraform CLI itself is one of many things involved in applying a configuration that has a version number. We wonder if perhaps it'd be more interesting to capture the version of the provider that most recently updated an object rather than the Terraform CLI version, because the provider's code has a lot more impact on the details of how that object is created than Terraform CLI's code does.

[garthkerr]

The version of the provider, or having a providers meta object could also be incredibly useful.

My use-case is more around workflow changes from one Terraform CLI version to the next. I use something like tfswitch to progressively update our modules to the latest version as the provider support becomes available and the state changes are validated. That way, I'm not trying to do a CLI version change across all modules in one shot.

Being able to, for example, apply tags to resources with the Terraform CLI version, gives an outside-in look at resources where the workflow still needs to be updated.

[garthkerr]

Was there any additional thought given to this?

[lifeofguenter]

Similar boat here: having something like terraform.version as pendant to terraform.workspace, or maybe even having access to the provider version would be really helpful.

Certain terraform modules we write might have minimal changes between 0.12/0.13 (or provider version jumps) that we can easily build in compatibility, if the version is known.

There are of course tons of other ways to solve this (like properly version tagging modules), but we feel like just having terraform.version exposed is a simple fix.

[lifeofguenter]

Actually this was much easier than expected as we already heavily rely on https://github.com/tfutils/tfenv, which means all our projects and modules have a .terraform-version in their root folder:

locals {
  terraform_version       = chomp(file("${path.root}/.terraform-version"))
  terraform_version_major = regex("^\\d+\\.\\d+", local.terraform_version)
}

if you want to rely on the "module's version" you can also use path.module instead of path.root. They way we wrap terraform, .terraform-version is the source of truth.

[garthkerr]

There are workarounds to getting the version. The intent of the feature request is to formalize it as a native property.