20 Commits (580d3afb34633ee558b54a5604ca89fd032ca2ee)

Author	SHA1	Message	Date
Liam Cervante	5939efb798	stacks: add depends_on for embedded stacks and components (#35549)	2 years ago
Liam Cervante	33c0ae7f09	stacks: add additional provider validation tests (#35471)	2 years ago
Liam Cervante	8e47b5907c	stacks: provide more helpful diagnostics when providers types are mismatched (#35422) ... * stacks: provide more helpful diagnostics when providers types are mismatched * remove left over implementation experiments * remove unnecessary fmt.Sprintf * address comments * fix incorrect pluralisation * fix tests	2 years ago
Daniel Schmidt	bf5037fa05	stacks: add test case	2 years ago
Daniel Schmidt	05755422f3	stacks: pass dependency lock in tests	2 years ago
Liam Cervante	7a8ffff66e	stacks: Fix unknown provider values crashing validation phase (#35155) ... * test to reproduce * stacks: Fix unknown provider values crashing validation phase * remove extra type information --------- Co-authored-by: CJ Horton <cjhorton@hashicorp.com>	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
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
Alisdair McDiarmid	1459825e53	Merge pull request #34725 from hashicorp/alisdair/configs-sourcebundle-parser ... Add and use a source bundle aware configuration parser for stacks	2 years ago
Liam Cervante	b2cc7dbadf	stacks: validate the types of input variables during validation (#34722)	2 years ago
Liam Cervante	831630fabe	stacks: the plan function should stop on validation errors (#34720)	2 years ago
Alisdair McDiarmid	97a220fb82	stacks: Use source bundle aware config parser	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
Martin Atkins	d1b0632e82	stackruntime: Add HashiCorp copyright comments	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	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