5 Commits (8fd8a48a06af33d3a3614b4b48768bd1516632fe)

Author	SHA1	Message	Date
Radek Simko	0fe906fa8c	make copyrightfix	2 months ago
Daniel Banck	6d7f801483	backends: Fix crash when interrupting during interactive prompt for values' (#36448) ... * backends: Convert null values to empty objects before coercion * backends: add test case for interrupt crash * Add changelog	1 year ago
Martin Atkins	660ff86c4c	backendbase: Preserve unset arguments as null when not set by env ... Previously we tried a simplification where any attribute with an "SDK-like default" was guaranteed to never be null, because that seemed like a plausible mimic of the legacy SDK's general aversion to nulls. However, the SDK does still respect the absense of an argument as different to its zero value in one narrow case: when the argument isn't set in the configuration, also isn't set by any environment variables, and has no static fallback default. In that case, the SDK's built-in validation rules such as "ConflictsWith" _do_ treat absent as different from zero-value. To allow backends to continue making such distinctions themselves where that's useful, SDKLikeDefaults now leaves an attribute set to null if it wasn't present in the configuration and none of the environment variables or fallback value cause it to end up being a non-empty string. The backend can then choose to bypass the SDKLikeData API and check the cty.Value directly if it wants to distinguish set from zero even though SDKLikeData is designed to avoid the need to do that. This also updates the gcs backend to make use of the new facility, since it wants to raise an error if two arguments are both set even if they are both set to the empty string. Restoring that original error case is the main motivation for this change.	2 years ago
Martin Atkins	6bd1c66cbc	backendbase: Basic support for default values ... Some existing backends make very heavy use of environment variable-based default values and fallback values, which are available in the legacy SDK but not in Terraform's own schema model. To ease the migration away from the legacy SDK for those backends, backendbase.Base now supports a lightweight mechanism for declaring such defaults, and applies them automatically as part of PrepareConfig. This gets us pretty close to the assumptions that the SDK allowed callers to make, but with considerably less code. It's intentionally considerably less flexible than the legacy SDK was, because in practice most backends use only a tiny subset of the SDK functionality anyway.	2 years ago
Martin Atkins	df4cefbea9	backend: new "backendbase" helper package ... This is intended as a lighter-weight replacement for the Backend type in the legacy/helper/schema package, which indirectly pulls in our local copy of the entire legacy Terraform plugin SDK. This depends on the slightly-lower-level configschema package, which means that it's not quite as feature-rich as what it's replacing, but backends have relatively modest needs and so we can compensate with just some extra logic in their Configure functions, which will be considerably simpler than the huge bunch of legacy code we're currently depending on to get the same effects. In particular, configschema has no concept of "default values" for arguments, and so we'll need to deal with those in the Configure methods using imperative code, instead of declaratively. Nothing is using this yet, but in future commits we'll gradually convert all of the remote state backends to use this instead of the legacy system, and then remove the legacy system.	2 years ago