backend: Undeclared variables in -var-file is a warning, not an error #20057
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 Terraform 0.11 and earlier we just silently ignored undeclared variables in
-var-file
and theautomatically-loaded
.tfvars
files. This was a bad user experience for anyone who made a typo in a variable name and got no feedback about it, so we made this an error for 0.12.However, several users are now relying on the silent-ignore behavior for automation scenarios where they pass the same
.tfvars
file to all configurations in their organization and expect Terraform to ignore any settings that are not relevant to a specific configuration. We never intentionally supported that, but we don't want to immediately break that workflow during 0.12 upgrade.As a compromise, then, we'll make this a warning for v0.12.0 that contains a deprecation notice suggesting to move to using environment variables for this "cross-configuration variables" use-case. We don't produce errors for undeclared variables in environment variables, even though that potentially causes the same UX annoyance as ignoring them in vars files, because environment variables are assumed to live in the user's session and this it would be very inconvenient to have to unset such variables when moving between directories. Their "ambientness" makes them a better fit for these automatically-assigned general variable values that may or may not be used by a particular configuration.
This can revert to being an error in a future major release, after users have had the opportunity to migrate their automation solutions over to use environment variables.
We don't seem to have any tests covering this specific situation right now. That isn't ideal, but this change is so straightforward that it would be relatively expensive to build new targeted test cases for it and so I instead just hand-tested that it is indeed now producing a warning where we were previously producing an error. Hopefully if there is any more substantial work done on this codepath in future that will be our prompt to add some unit tests for this.
This closes #19424.