We intentionally allow assigning object types with a superset of the
attributes included in an input variable's object type constraints because
it makes it possible to assign a whole object for which only some of the
attributes are relevant for one input variable but a different subset might
be relevant when the object value is used in a different part of the
configuration.
However, when the variable is defined using an object literal expression
there is no possible way an unexpected attribute could be useful in a
different part of the configuration, and so that's very very likely to be
a mistake rather than intentional. Therefore we'll generate a "linter-like"
warning in that case to help the author notice their mistake without
introducing any new "strict-mode" language features, or other complexity
that would be harder to maintain and evolve over time.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is the first version of go-getter that uses AWS SDK for Go v2, instead
of the now-obsolete SDK v1. This means that we no longer have an indirect
dependency on the obsolete SDK version, and so should generate less noise
for security scanners that are configured to check for unmaintained
dependencies.
This does unfortunately also force upgrading some of the AWS SDK v2
dependencies, which potentially affects the "s3" backend too. This is the
typical risk of having all of these external integrations linked
directly into our executables, but most of these are just minor upgrades
that we likely would've adopted in the near future anyway.
The newer version of go-getter also uses newer versions of some of its
other dependencies, but we were already on newer versions of most of them
anyway and so the main effect here is just to drop the older versions from
our go.sum file now that they are no longer included in the module version
selection process.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This introduces the concept of "backend aliases", which are alternative
names that can be used to refer to a given backend.
Each backend type has one canonical name and zero or more alias names. The
"backend" block in the root module can specify either a canonical backend
type or an alias, but internally OpenTofu will always track the backend
type using its canonical name.
In particular, the following are all true when the configuration specifies
an alias instead of a canonical backend type:
- The "tofu init" output includes a brief extra message saying which
backend type OpenTofu actually used, because that is the name that we'd
prioritize in our documentation and so an operator can use the canonical
type to find the relevant docs when needed.
- The .terraform/terraform.tfstate file that tracks the working directory's
currently-initialized backend settings always uses the canonical backend
type, and so it's possible to freely switch between aliases and canonical
without "tofu init" thinking that a state migration might be needed.
- Plan files similarly use the canonical backend type to track which
backend was active when the plan was created, which doesn't have any
significant user-facing purpose, but is consistent with the previous
point since the settings in the plan file effectively substitute for
the .terraform/terraform.tfstate file when applying a saved plan.
- The terraform_remote_state data source in the provider
terraform.io/builtin/terraform accepts both canonical and alias in its
backend type argument, treating both as equivalent for the purpose of
fetching the state snapshot for the configured workspace.
The primary motivation for this new facility is to allow the planned
"oracle_oci" backend to have an alias "oci" to allow writing configurations
that are cross-compatible with HashiCorp Terraform, since that software
has chosen to have unqualified OCI mean Oracle's system, whereas OpenTofu
has previously established that unqualified OCI means "Open Container
Initiative" in our ecosystem.
In particular, this design makes it possible in principle to bring an
existing Terraform configuration specifying backend "oci" over to OpenTofu
without modifications, and then to optionally switch it to specifying
backend "oracle-oci" at a later time without a spurious prompt to migrate
state snapshots to the same physical location where they are already
stored.
This commit doesn't actually introduce any aliases and therefore doesn't
have any tests for the new mechanism because our backend system uses a
global table that isn't friendly to mocking for testing purposes. I've
tested this manually using a placeholder alias to have confidence that it
works, and I expect that a subsequent commit introducing the new
"oracle_oci" backend will also introduce its "oci" alias and will include
tests that cover use of the alias and migration from the alias to the
canonical name and vice-versa.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
These were previously settable only via environment variables. These are
now handled as part of CLI Configuration and so also settable in a new
"registry_protocols" block in a CLI configuration file, with the
environment variables now treated as if they are an additional virtual
configuration file containing the corresponding settings.
This handles our settings in our modern style where package cliconfig is
responsible for deciding the configuration and then package main reacts
to that configuration without being aware of how it is decided.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
ORAS v1.3.0 introduces some new features that allow directly building an
index manifest in the form that OpenTofu expects, so it's no longer
necessary to edit that index manifest manually.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The handling of deprecation marks is currently tested mainly in a context
test (i.e. integration test) over in package tofu, but it's nice to also
have some nearby unit test coverage and so this is an initial step in that
direction which we could choose to extend in later commits.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
In the previous commit we upgraded to cty v1.17.0, which already gave us
some performance improvements for functions like UnmarkDeepWithPaths.
However, this release also includes some new functions that allow more
surgical work with marks, and so we can get some additional gains by using
those in the codepaths related to deprecation tracking.
In particular, using WrangleMarksDeep instead of UnmarkDeepWithPaths means
that we can tell cty that we only want to remove the deprecation-related
marks, and so when given a value that contains only non-deprecation-related
marks it can avoid constructing a new cty.Value altogether, and instead
just return the one that was given. In the case where there _are_
deprecation-related marks, it will rebuild only the parts of the data
structure that lead to those marks. Deprecation-related marks are rare in
practice, so this should be a relatively good payoff.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This release includes various performance improvents to the marks-related
functionality, which is beneficial to OpenTofu because we've been making
increasingly more use of marks for new use-cases lately.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
