We encovered that deferred action invocations don't get provider
addresses, which prevents us from loading the schema. That being said, I
think it shouldn't be an issue, but will come back to revisit this as we
build the support end to end.
Add a test for deferred actions support
* stacks: fix bug preventing cross-provider move refactorings
* also make provider functions work
* stacks: add support for provider functions in .tfstack.hcl files
* stacks: add deferred resource instance planned change to protobuf
* stacks: add deferred resource instance to stack plan sequence
* stacks: add planned change for deferred actions
* stacks: refactor planned change resource instance planned
moving the components out of the main function definition so that we can reuse the implementation for deferred resource instances which wraps the message used for PlannedChangeResourceInstancePlanned
* stacks: track deferred changes in stackplan
* add simple tests
* fix tests
* address comments
---------
Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com>
Components can emit sensitive values as outputs, which can be consumed
as inputs to other components. This commit ensures that such values are
correctly processed in order to pass their sensitivity to the modules
runtime.
This means it's valid to write references like "component.foo" in
expressions in a stack configuration, where the result is built from the
planned output values of the root module of each component instance.
For embedded stacks we intentionally designed the language to require
explicit types on all output values so that we'd still be able to do type
checking even when we can't calculate the output values yet. Unfortunately
we can't do the same trick for components because the main Terraform
module language treats output values as dynamically-typed and so an
output value we can't evaluate yet could have literally any type.
Therefore we concede and just return cty.DynamicVal in most failure cases
here; perhaps a future edition of the main Terraform language can improve
this by requiring explicitly-typed output values there too.
This is the public entry point for the overall validation of an entire
stack configuration. So far it supports validation only of input variables,
embedded stack calls, and output values. We'll grow this to support other
language constructs in later commits.
This is a relatively large commit due to introducing various supporting
infrastructure to help make evaluation possible at all. Subsequent commits
will hopefully be more focused due to being able to depend on the
foundations introduced here.
This stubs out the basic structure of stackeval's equivalent of a graph
walk, which is really just a recursive tree walk starting async tasks that
might depend on each other via the abstractions in package "promising".
This initial work is sufficient to validate the inputs to an embedded
stack call when referring to input variables in the calling stack, showing
that the expression evaluation model seems to be working and the use of
promises to deal with dependency ordering seems viable.
