* Add component registry source resolution support to Terraform Stacks
This change implements the missing component source resolution case in the stack configuration loader, enabling Terraform Stacks to properly handle component registry sources from HCP Terraform and other component registries.
The implementation mirrors the existing module registry resolution workflow, where component sources are first resolved to their versioned form using the source bundle's component metadata, then converted to final source addresses that can be used to locate the actual component code. This completes the integration between the terraform-registry-address component parsing capabilities and the go-slug sourcebundle component resolution APIs.
* chore: bump go-slug to v0.18.1
* fix: add case for component final source type
* chore: rm space
* chore: sync module deps
* chore: update testdata with separate bundle
* fix: manifest file json obj with trailing comma
* Add changelog entry to 1.14
---------
Co-authored-by: Michael Yocca <michael.yocca@hashicorp.com>
This should eventually have the same meaning as it does for the modules
language under the ephemeral_values language experiment, but as of this
commit is just accepted during decoding and then ignored. The rest of the
functionality will follow in subsequent commits.
There's no specific experiment guard in this case because the stack
configuration language is already experimental as a whole anyway.
Because many stacks language features are dependent on others to do useful
work, it's tempting to focus only on integration testing of combinations
of features used together. However, we known from our experience with the
modules runtime (the "terraform" package) that over time this becomes a
huge maintenance burden, because any non-trivial change tends to
invalidate hundreds or thousands of integration tests, and because of their
broad scope its often hard in retrospect to figure out what exactly a
particular test was aiming to test vs. what it was just relying on as a
side-effect.
To try to minimize these cross-dependencies and thus enable something
closer to unit testing, here we introduce a special kind of symbol to the
stacks language which is available only to unit tests in this package.
"Test-only globals" -- an intentionally-clunky name to avoid squatting on
useful names -- can be set as part of the Main object and, when defined,
are available for use in all situations where we perform expression
evaluation against a stack. The "globals" in the name represents that,
unlike just about everything else, they are defined once but available in
all stacks in the configuration tree.
This design is a tradeoff: it introduces a bunch of extra code that is
here entirely to support testing, but hopefully this code is segregated
enough from everything else that it's unlikely to change significantly
under future maintenance, thereby hopefully minimizing the need for future
cross-cutting test maintenance too.
Instead of the temporary hack of hard-coding the built-in "terraform"
provider, it's now possible to declare configurations for arbitrary
providers and assign them to the provider configuration slots of the root
module of each component.
Each declared provider configuration is now started up and configured
during planning. We don't actually do anything with them yet other than
shut them down again once the plan is complete, but we'll improve on that
in subsequent commits.
When we load stackconfig we don't immediately load any of the modules that
component blocks refer to, so we need to bring the source bundle along
with the configuration so that a downstream piece of code (the stack
language runtime, currently) can load those from the same source bundle.
Previously we placed "typeexpr" under "internal" to represent that it
wasn't for use by other parts of Terraform, but that was too strict: the
Stacks runtime needs to be able to import this package to access the
Defaults API.
For now we'll make it importable by the whole of Terraform. However, in
a later commit we might wish to establish an internal subdirectory directly
under "stacks" for packages that are only for stacks-related functionality,
since this "typeexpr" contains Stacks-specific logic and the rest of
Terraform ought to be using HCL's own "typeexpr" package instead.
This is a first pass for decoding the new stack configuration language,
which is overall pretty similar to the Terraform module language but does
have some intentional differences both in its top-level concepts -- has
embedded stacks and components instead of nested modules and resources --
and in its details, where we're making use of some learnings about where
folks have struggled with the Terraform module language.
This initial implementation should be enough for us to experiment with but
we'll probably iterate on this more in later commits as we learn from
implementing a language runtime for this and from actually trying to use
the language for real use-cases.
