terraform: Stabilize the variable_validation_crossref experiment #34955
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #34947 we introduced a language experiment that would permit variable validation rules to refer to other objects declared in the same module as the variable.
Now that experiment is concluded and its behavior is available for all modules.
This closes #25609.
This final version deviates slightly from the experiment: we learned from the experimental implementation that we accidentally made the
terraform validate
command able to validate constant-valued input variables in child modulesdespite the usual rule that input variables are unknown during validation, because the previous compromise bypassed the main expression evaluator and built its own evaluation context directly.
Even though that behavior was not intended, it's a useful behavior that is protected by our compatibility promises and so this commit includes a slightly hacky emulation of that behavior, in
eval_variable.go
, that fetches the variable value in the same way the old implementation would have and then modifies the HCL evaluation context to include that value, while preserving anything else that our standard evaluation context builder put in there.That narrowly preserves the old behavior for expressions that compare the variable value directly to a constant, while treating all other references (which were previously totally invalid) in the standard way. This quirk was already covered by the existing test
TestContext2Validate_variableCustomValidationsFail
, which fails if the special workaround is removed.