This symbol produces an ephemeral boolean value that's true when the
stack evaluator is configured for applying and false otherwise.
The primary purpose of this is to allow specifying a more privileged auth
role in a provider configuration during the apply phase, while allowing
the plan phase to use a read-only or otherwise-less-privileged role.
This allows us to talk about references between expressions in absolute
terms, taking into account the stack where a particular expression would
be resolved.
This isn't an appropriate representation for references like each.key,
since those require a more specific scope than just a stack, but that's
okay because those contextual reference types can't depend on anything
other than what they are embedded inside anyway, and so we never need to
consider them when we're doing global reference analysis.
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.
This is a sketch of the overall structure of the prior state decoder and
the model type it populates.
Before we can complete this we'll need to slightly rework how the apply
phase emits the raw events that this is consuming, and in particular to
change the raw state representation to be JSON-based to match with how
Terraform Core expects to receive it once reloaded. That will follow in
later commits.
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.
Addresses of this type will appear in some of our serialization formats
and so we need a parser function which provides the inverse of the
"String" method of this type.
In the stacks model a component is essentially a container for a tree of
normal Terraform modules, and so anything that can appear in a Terraform
module can in principle appear inside a component.
With that in mind here we define a generic type that can represent
anything from package addrs belonging either to a stack configuration
(before instance expansion) or to a stack instance (after instance
expansion), and some aliases for a few combinations that make sense
together, such as stackaddrs.AbsResourceInstance being an
addrs.AbsResourceInstance belonging to a stackaddrs.AbsComponentInstance.
We'll probably add more aliases here later, but this is a starting set
that I expect will arise while implementing the planning-related models
for stacks.
If a stack configuration has a dependency cycle we'll tend to detect it
by the promises failing to resolve due to a self-reference. Describing
that situation to end-users has been historically hard in existing
Terraform's dag-based implementation, and there are some similar
challenges for this promise-based design too.
To deal with it while minimizing runtime overhead in the happy path we'll
teach the various objects to retroactively report names for the promises
they've already instantiated and then only when we encounter the
ErrSelfDependent error will we walk the tree of objects to find
user-friendly names for all of the promises that have contributed to the
results so far.
