Allow magic variables in variable validation

[SizZiKe]

Current Terraform Version

0.14.5

Use-cases

• Constraining variables against Terraform workspaces
• Constraining variables against content in configuration files, e.g. ensuring a value exists in a YAML or JSON file within the module directory

Attempted Solutions

• no workarounds for terraform.workspace
• path.module can be omitted when referencing a file but can lead to unexpected results if the module doesn't lie within the working directory

Proposal

The good references check should exempt magic variables (path.*, terraform.workspace, etc.)

References

[sambuysse]

+1 would also like to check if a variable's value is present in json/yaml config file which contains a list of valid values. So access to path.module, or any other for that matter, would be nice.

[bschaeffer]

HEAVY PLUS SIGN

[nickattardgsys]

This is a sorely needed feature. Trying to validate some inputs based on a reasonably long list (about 300 lines) makes the code look very untidy.

Loading a file from a path to then validate the variable against is super useful. It works, but not in modules since path.module is apparently a reference to a variable outside the variable itself. Really unfortunate.

variable "organisation_tags" {
  description = "Tags for financial reports, information from one identity"
  type = object({
    division      = optional(string)
    department    = optional(string)
    business-area = optional(string)
    team          = optional(string)
  })
  validation {
    condition = alltrue([
      var.organisation_tags.division == null ? true : contains(compact(split("\n",file("${path.module}/files/list.csv"))), format("%s,%s,%s,%s",var.organisation_tags.division, var.organisation_tags.department, var.organisation_tags.business-area, var.organisation_tags.team)),
    ])
    error_message = format("%s\n%s", 
    tostring(<<EOF
    Valid values:
    Kindly set the "division,department,business-area,team" from the list.
    EOF
    ),
    join(" | " ,compact(split("\n",file("${path.module}/files/list.csv"))))
    )
  }
  default = {
    division      = null
    department    = null
    business-area = null
    team          = null
  }
}

This is the variable in the module and the error when using it with path.module:

│ Error: Invalid reference in variable validation
│ 
│   on .terraform/modules/application_stack_tags/variables.tf line 11, in variable "organisation_tags":
│   11:       var.organisation_tags.division == null ? true : contains(compact(split("\n",file(${path.module}, "/files/list.csv"))), format("%s,%s,%s,%s",var.organisation_tags.division, var.organisation_tags.department, var.organisation_tags.business-area, var.organisation_tags.team)),
│ 
│ The condition for variable "organisation_tags" can only refer to the variable itself, using var.organisation_tags.

[chris3ware]

Being able to constrain the variable to a terraform workspace, as the op has suggested, would be very useful. For example:

Workspaces:

• dg-egress-nonprod
• dg-egress-prod

terraform.tfvars

network_cidr_blocks = {
  dg-egress-nonprod = {
    lob-eg-cidr-dev = "192.0.2.0/24"
    lob-eg-cidr-tst = "198.51.100.0/24"
  }
  dg-egress-prod = {
    lob-eg-cidr-prd = "203.0.113.0/24"
  }
}

variables.tf

variable "network_cidr_blocks" {
  description = "The CIDR blocks assigned to the service"
  type        = map(map(string))
  default     = {}
  nullable    = false
  validation {
    condition = alltrue(
      [for k in keys(var.network_cidr_blocks["${terraform.workspace}"]) : can(regex("^[a-z]+((?:-[a-z]+)*)$", k))]
    )
    error_message = "Invalid input. Use all lowercase characters separated by hyphens. eg: \"palo-alto-firewalls\""
  }
}

Unless there is a better way to test the keys lob-eg-cidr-dev, log-eg-cidr-tst, and lob-eg-cidr-prd ?

[apparentlymart]

Hi all,

We've recently merged #34955 with the intention of including support for this in the forthcoming Terraform v1.9 release.

Thanks for the feature request!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.