Improve handling of TF_INPUT env variable

[mss]

Describe the Feature

In our CI we have the environment variable TF_INPUT=false set to avoid any stalls due to unset variables and fail instead.

This was no issue in our current version but in v1.160.2 we now get the warning

WARN detected 'TF_INPUT' set in the environment; this may interfere with Atmos's control of Terraform.

There should be a way to handle this one variable more graceful since it looks like this is a generic check at https://github.com/cloudposse/atmos/blob/v1.160.2/internal/exec/terraform.go#L222 but no other part of the code makes use of this variable.

Expected Behavior

No warning about TF_INPUT=false.

Use Case

Avoid any hangs due to terraform waiting for input in a CI environment (or a local dev environment where I prefer it to fail instead of asking me pointless questions).

Describe Ideal Solution

Add an allowlist for know-good variables and maybe their values. TF_INPUT or maybe TF_INPUT=false should be such a case.

Alternatives Considered

No response

Additional Context

I also get a warning about TF_CLI_CONFIG_FILE since I like my system to follow the xdg spec but haven't looked into that one in detail.

[osterman]

@Nuru can you share your similar requirements

[osterman]

warn only at a non-default log level

I would be open to changing the warning to a debug level.

[osterman]

From @Nuru:

Other variables that should not be warned about:

• TF_PLUGIN_CACHE_MAY_BREAK_DEPENDENCY_LOCK_FILE which is a common choice
• TF_PLUGIN_CACHE_DIR which is also a common setting and which Terraform will warn you about itself it is causing a problem. (More specifically, it will tell you if the cache dir is a problem, though you could have set it in ~/.terraformrc.)
• TF_LOG, TF_LOG_CORE, TF_LOG_PROVIDER, and TF_LOG_PATH all only affect logging
• TF_IN_AUTOMATION which is intended to be set and affect operations
• TF_REGISTRY_DISCOVERY_RETRY
• TF_REGISTRY_CLIENT_TIMEOUT
• TF_STATE_PERSIST_INTERVAL
• TF_CLI_CONFIG_FILE

TF_DATA_DIR is an interesting case, in that when you want it, you want it, but it can cause issues with Atmos if it is set differently than Atmos expects.

Possible solutions (not mutually exclusive)

• configurable whitelist
• configurable blacklist
• warn only when an env var conflicts with an Atmos setting
• warn only at a non-default log level
• have a separate switch (YAML config, command-line option) controlling this specific warning

Note that lists will have to allow for at least minimal pattern matching to handle TF_CLI_ARGS_<command> and TF_VAR_<var> variables.