5 Commits (stacks-variable-validations)

Author	SHA1	Message	Date
Liam Cervante	a80220dcc9	stacks: rename .tfstack files to .tfcomponent (#37013) ... * stacks: rename .tfstack files to .tfcomponent * fix consistency issues	1 year ago
Martin Atkins	afd2282aa6	stacks/stackruntime: fix TestPlanWithSingleResource ... We've now upgraded the go-slug dependency to a newer version that fixed the bug that this FIXME comment was referring to, so we can now write the source address correctly and remove the note.	3 years ago
Martin Atkins	c1e7abafc3	stackruntime: Configure and assign provider instances ... 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.	3 years ago
Martin Atkins	ea3b70abf0	stackeval: Component calls are now referenceable ... 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.	3 years ago
Martin Atkins	4a179ed969	stackeval: Very very basic component planning ... This is the absolute bare-minimum integration with the main Terraform language runtime to plan changes for a component. It's intentionally not yet very robust and limited only to the built-in Terraform provider because we're just trying to get the bones in place for seeing stack planning working, rather than trying to build something complete enough to ship. This currently only deals with the resource instance changes that get planned and doesn't expose the root module's output values for use elsewhere in the stack configuration. Output value handling will follow in subsequent commits.	3 years ago