* Add testing helpers for comparing diagnostics with different levels of stringency
* Refactor some existing tests to use the new helpers
* Replace use of diag comparison test helpers in terraform package
* Add header
* Add return statement back in ephemeral test
* Update internal/terraform/context_plan2_test.go
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.
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.
A lot of the remote state backends' current Configure functions
unfortunately rely quite heavily on the "do the best you can" API of the
legacy SDK, which makes questionable shortcuts like treating null as
equivalent to the Go zero value of a type, but in return makes it
convenient to assign into other data structures that happen to make
similar assumptions. And of course that means that the backends' other
data structures were built to make those similar assumptions!
This new set of utilities therefore aims to provide a bare-minimum subset
of "SDK-like" functionality to ease the initial migration away from the
legacy SDK. It isn't exactly equivalent an in particular focuses only on
the small subset of legacy SDK functionality that most existing backends
rely on, but this should at least make the initial adaptations a little
more mechanical so that we can continue to defer the full modernization
of these backends for some undetermined future time without having to
continue retaining the huge legacy SDK snapshot in this codebase.
With legacy helper/schema it's common to just type-assert whatever
ResourceData.Get returns and trust that it'll always be valid. We can't
achieve something quite that lazy with cty, but we can at least factor
out the work of turning a value we already know is a bool into a bool
value.
We also have a "must" variant for this one, because it's relatively easy
for a caller to ensure that it controls all of the inputs enough to
ensure that it should never fail.
With legacy helper/schema it's common to just type-assert whatever
ResourceData.Get returns and trust that it'll always be valid. We can't
achieve something quite that lazy with cty, but we can at least factor
out the work of turning a value we already know is a number into an int64
value.
The legacy helper/schema based Backend implementation expected the
backend-specific code to return error and then wrapped it in diagnostics
itself before returning.
Backends using backendbase are supposed to return diagnostics directly
themselves, but having to manually replace every error case with a
higher-quality diagnostic message would get in the way of EOLing the
legacy helper/schema implementation, and so this helper function is a
pragmatic compromise to allow us to keep those updates purely mechanical
for now and then improve diagnostics as a separate effort later.
Most of the remote state backends are currently written in terms of
schema.ResourceData, lookup up attributes by path and possibly
substituting default values when the attributes aren't explicitly set.
These helpers aim to substitute for those common applications so that we
can convert the existing backend logic more directly, without significantly
increasing its complexity by suddenly moving the default value handling
inline in their Configure functions.
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.
