2020-01-04 02:12:49 +01:00
|
|
|
|
|
|
|
|
locals {
|
|
|
|
|
foo = 1
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
variable "validation" {
|
|
|
|
|
validation {
|
|
|
|
|
condition = local.foo == var.validation # ERROR: Invalid reference in variable validation
|
|
|
|
|
error_message = "Must be five."
|
|
|
|
|
}
|
|
|
|
|
}
|
core: Check rule error message expressions
Error messages for preconditions, postconditions, and custom variable
validations have until now been string literals. This commit changes
this to treat the field as an HCL expression, which must evaluate to a
string. Most commonly this will either be a string literal or a template
expression.
When the check rule condition is evaluated, we also evaluate the error
message. This means that the error message should always evaluate to a
string value, even if the condition passes. If it does not, this will
result in an error diagnostic.
If the condition fails, and the error message also fails to evaluate, we
fall back to a default error message. This means that the check rule
failure will still be reported, alongside diagnostics explaining why the
custom error message failed to render.
As part of this change, we also necessarily remove the heuristic about
the error message format. This guidance can be readded in future as part
of a configuration hint system.
2022-02-03 20:14:21 +01:00
|
|
|
|
|
|
|
|
variable "validation_error_expression" {
|
|
|
|
|
validation {
|
|
|
|
|
condition = var.validation_error_expression != 1
|
|
|
|
|
error_message = "Cannot equal ${local.foo}." # ERROR: Invalid reference in variable validation
|
|
|
|
|
}
|
|
|
|
|
}
|