21 Commits (3d211eb42ffcdc9d33d56bc2785d64b22f158c39)

Author	SHA1	Message	Date
Alisdair McDiarmid	f409639934	Merge pull request #34765 from hashicorp/alisdair/stack-root-input-variable-defaults ... stackruntime: Apply defaults to root variables	2 years ago
Alisdair McDiarmid	f3ec86b17b	stackruntime: Treat unset and null equally ... When handling root input variable values, we now consider unset and null values to be equivalent to each other. This is consistent with how we handle variables in embedded stacks, and very similar to how we handle variable in the modules runtime with `nullable = false`. One difference from the modules runtime case is that we do not prevent a null default value for stack variables.	2 years ago
Alisdair McDiarmid	0fe26468cd	stackruntime: Apply defaults to root variables ... When evaluating a stack's root input variables, supplied by the caller, we must apply any default values specified in the variable configuration for variables with no specified value. This commit adds this default fallback case, using NilVal as a marker indicating the lack of a specified value. If no default value exists for a variable, it is therefore required to be supplied by the caller. This commit also reports a diagnostic error in this case.	2 years ago
CJ Horton	5a750561e6	round-trip check results through stack plans ... Components expect that check results will be round-tripped through the plan in order to update unknown check results during the apply. We hadn't wired this up for stack plans, resulting in panics when the apply tries to update a check status that doesn't exist.	2 years ago
Liam Cervante	cec4b7b74c	stacks: validate providers based on types instead of local names (#34735) ... * stacks: validate providers based on types instead of local names * fix tests	2 years ago
Liam Cervante	31a7fa88d5	stacks: validate provider configurations during static analysis (#34730)	2 years ago
Liam Cervante	b2cc7dbadf	stacks: validate the types of input variables during validation (#34722)	2 years ago
Liam Cervante	b3abff5750	stacks: check providers blocks in components during validatation (#34707)	2 years ago
Liam Cervante	bced645a4d	stacks: call terraform.Validate on stack component configs (#34705)	2 years ago
Liam Cervante	64b311d53a	stacks: apply sensitive marks to outputs from components (#34684) ... * stacks: apply sensitive marks to outputs from components * gen headers * ensure consistent test ordering	2 years ago
Liam Cervante	07f6621091	stacks: include resources in state when calculating required providers (#34645) ... * stacks: include resources in state when calculating required providers * also support apply time * add copywrite headers	2 years ago
Liam Cervante	3475d22741	Fix nil pointer exception when planning stacks with undeclared variables (#34638) ... * fix nil pointer exception when planning with undeclared variables * another function does the same	2 years ago
Alisdair McDiarmid	1d3f863f2b	stackruntime: Support sensitive component inputs ... 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.	2 years ago
Alisdair McDiarmid	e4b319401e	stacksruntime: Add sensitive outputs tests	2 years 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.	2 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.	2 years ago
Martin Atkins	3dc3781904	stackruntime: Starting up and configuring provider plugins ... 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.	2 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.	2 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.	2 years ago
Martin Atkins	791a5fb8a6	stackruntime: Top-level "Validate" function ... 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.	2 years ago
Martin Atkins	4754889950	stackruntime: Beginnings of Validate function ... 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.	2 years ago