IssueRaiser

Allow warning messages within variable validation

### Terraform Version ```shell Terraform v1.3.7 ``` ### Use Cases I want to be able to raise a warning in a Terraform module, similar to how a provider raises a warning for deprecated arguments. We focus heavily on maintaining backwards compatibility and giving time to transition how modules are used, so we end up deprecating module variables in favor of new variables from time to time. We document this in variable descriptions and the logic that uses them handles the logic for transitioning, but being able to clearly highlight the deprecations in the plan would be very useful as well. ### Attempted Solutions The way we accomplish this today is simply in descriptions, readme/documentation, and in the implementation of the variables. As a highly simplified example, we may want to change the name of a variable as we update legacy modules to use standard variable name structures and input types across all our modules. ```hcl variable "name" { description = "The name of the bucket to create. DEPRECATED: Use bucket_name instead. If bucket_name is provided, this string is ignored." type = string default = "" } variable "bucket_name" { description = "The unique name of the bucket to create. This will be combined with the environment name to create the final bucket name." type = string default = "" } variable "environment" { description = "The environment name for this resource." type = string } locals { # Compare two variabl

Posted by derekwinters on Jan 27, 2023, 10:38 PM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.2,500 issues0 comments

github (Other)

Allow warning messages within variable validation

derekwintersJan 27, 2023, 10:38 PM

### Terraform Version ```shell Terraform v1.3.7 ``` ### Use Cases I want to be able to raise a warning in a Terraform module, similar to how a provider raises a warning for deprecated arguments. We focus heavily on maintaining backwards compatibility and giving time to transition how modules are used, so we end up deprecating module variables in favor of new variables from time to time. We document this in variable descriptions and the logic that uses them handles the logic for transitioning, but being able to clearly highlight the deprecations in the plan would be very useful as well. ### Attempted Solutions The way we accomplish this today is simply in descriptions, readme/documentation, and in the implementation of the variables. As a highly simplified example, we may want to change the name of a variable as we update legacy modules to use standard variable name structures and input types across all our modules. ```hcl variable "name" { description = "The name of the bucket to create. DEPRECATED: Use bucket_name instead. If bucket_name is provided, this string is ignored." type = string default = "" } variable "bucket_name" { description = "The unique name of the bucket to create. This will be combined with the environment name to create the final bucket name." type = string default = "" } variable "environment" { description = "The environment name for this resource." type = string } locals { # Compare two variabl

Comments (0)

No comments yet. Start the discussion.

Comment on this issue