Change variable validation error message type from string to expression

[joeaawad]

Submitted on behalf of a third-party: @cgetzen

All credit goes to @cgetzen for #25028 which originally made this change almost 10 months ago. I just updated it to resolve the merge conflicts since the original PR appears to be abandoned and I think this is a vital PR that would make a huge quality of life improvement for users and save me a lot of time answering questions from less experienced Terraform users.

Resolves #24407.
Resolves #24160.

This PR changes configs.VariableValidation.ErrorMessage from a string to an expression.

One consequence of this is that some of the validations on the error message (nilstring and lookslikesentence) are moved from the configs package to the terraform package and checked during Eval.

Tests

Template

This file is used as a template for the results below

variable "x" {
  default = "four"
  type    = string
  validation {
    condition     = length(var.x) > 5
    error_message = "not a sentence"
  }
}

Results

error_message

output

"Input '${var.x}' must be more than 5 characters."

Error: Invalid value for variable

  on main.tf line 6, in module "test":
   6:   x = each.key

Input 'one' must be more than 5 characters.

This was checked by the validation rule at module/variables.tf:4,3-13.


Error: Invalid value for variable

  on main.tf line 6, in module "test":
   6:   x = each.key

Input 'two' must be more than 5 characters.

This was checked by the validation rule at module/variables.tf:4,3-13.

[4, 3]

Error: Invalid validation error message

  on module/variables.tf line 6, in variable "x":
   6:     error_message = [4, 3]

Invalid validation error message result value: string required.

"Your string ${var.x} isn't long enough."

Error: Invalid value for variable

  on main.tf line 5, in module "test":
   5:   x = "four"

Your string four isn't long enough.

This was checked by the validation rule at module/variables.tf:4,3-13.

"not a sentence"

Error: Invalid value for variable

  on main.tf line 5, in module "test":
   5:   x = "four"

not a sentence

This was checked by the validation rule at module/variables.tf:4,3-13.


Error: Invalid validation error message

  on module/variables.tf line 1:
   1: variable "x" {

Validation error message must be at least one full English sentence starting with an uppercase letter and ending with a period
or question mark.

[hashicorp-cla]

All committers have signed the CLA.

[codecov]

Codecov Report

Merging #28044 (2d94abb) into main (e553869) will increase coverage by 0.00%.
The diff coverage is 61.72%.

Impacted Files	Coverage Δ
terraform/eval_variable.go	58.73% <59.42%> (+7.88%)	⬆️
configs/named_values.go	66.96% <75.00%> (-0.40%)	⬇️
internal/providercache/dir.go	67.34% <0.00%> (-6.13%)	⬇️
dag/marshal.go	61.90% <0.00%> (-1.59%)	⬇️
states/statefile/version4.go	58.19% <0.00%> (+0.23%)	⬆️

[joeaawad]

n.Expr appears to have been changed to expr a while back so this is just fixing the docstring since I noticed it when fixing the merge conflicts from the original PR

[cgetzen]

Hey @joeaawad, glad to see others have the same language requests. My PR was waiting on a review, but if you're able to get the required +1s you need on this I'll go ahead and close mine. Thanks!

[joeaawad]

Sounds good, thanks @cgetzen. Didn't mean to step on any toes, just saw the merge conflicts and lack of activity so was hoping to try to push this through in time for 0.15.0. Maintainers - is 0.15.0 a possibility or is that already locked? Happy to help in any way that I can to push this through in time.

[joeaawad]

@pkolyvas Does https://discuss.hashicorp.com/t/terraform-0-15-0-beta2-released/21368 mean that it is too late to get this change in for 0.15.0? How can I help push this along to get it out ASAP?

[joeaawad]

@jbardin Sorry to ping but this is causing active pain so trying to get some 👀 since this update has been open for ~3 weeks and you were assigned to the original PR

[joeaawad]

@apparentlymart @alisdair this was pretty skewered by #30401 refactor that lost the EvalContext so I'm pretty out of my depth here on how to get a string out of cr.ErrorMessage after the type of ErrorMessage is changed to hcl.Expression for the comparisons. Maybe it would make sense to add a new ErrorMessageExpr like the ConditionalExpr to hclsyntax/expression and have that produce the string?

Please advise on if there is a path forwards for me to do this or if it would be best handled by the HashiCorp team, but I do feel that there is a ton of value in pushing this forward, especially now that you are looking at pre and post conditions which could also benefit from being able to explain exactly what variable caused the error.

[alisdair]

Hi @joeaawad! Thanks for working on this, and I'm sorry I hadn't noticed it until now.

I agree with your assessment of the value in evaluating error messages as expressions, especially if we move forward with pre/postconditions or something similar. I had actually been working on a separate implementation of the same concept myself, as I hadn't seen this branch or PR. I'll be opening a pull request for that shortly, and if it's approved then I hope we'll have error message expressions in the 1.2 release.

I'm going to close this for now in favour of the other branch, rather than as you to do further work on this one. Thanks again for pushing this forward!

[joeaawad]

@alisdair awesome, glad to hear it, thanks a lot

[github-actions]

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