Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

backend: Undeclared variables in -var-file is a warning, not an error #20057

Merged
merged 1 commit into from
Jan 22, 2019

Conversation

apparentlymart
Copy link
Contributor

In Terraform 0.11 and earlier we just silently ignored undeclared variables in -var-file and the
automatically-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.

In Terraform 0.11 and earlier we just silently ignored undeclared
variables in -var-file and the automatically-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.
@apparentlymart apparentlymart added this to the v0.12.0 milestone Jan 19, 2019
@apparentlymart apparentlymart self-assigned this Jan 19, 2019
@apparentlymart apparentlymart requested a review from a team January 19, 2019 00:39
@apparentlymart apparentlymart merged commit 10bf4c7 into master Jan 22, 2019
@radeksimko radeksimko deleted the f-undecl-vars-warning branch January 22, 2019 16:10
@martinkellydigital
Copy link

Good way to push people to using workspaces. Shame workspaces aren't any good.

@ghost
Copy link

ghost commented Jan 18, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Jan 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
3 participants