243 Commits (580d3afb34633ee558b54a5604ca89fd032ca2ee)

Author	SHA1	Message	Date
Liam Cervante	bb73fb1d69	stacks: don't validate input variables during the apply phase (#35561)	2 years ago
Liam Cervante	5939efb798	stacks: add depends_on for embedded stacks and components (#35549)	2 years ago
Liam Cervante	38033b5c45	stacks: sort diags in test before comparison (#35550)	2 years ago
Liam Cervante	915b174da3	stacks: split the terraform1 RPC package into per-service packages (#35513) ... * stacks: split the terraform1 RPC package into per-service packages * pull latest changes	2 years ago
Liam Cervante	46393f2a92	stacks: apply automatic type conversion before comparing inputs (#35530) ... * stacks: apply automatic type conversion before comparing inputs * correct error message for missing ephemeral value during apply	2 years ago
Liam Cervante	0c67edd598	stacks: ensure input values for components don't change between plan and apply (#35489) ... * stacks: ensure input values for components don't change between plan and apply * skip ephemeral values	2 years ago
Liam Cervante	33c0ae7f09	stacks: add additional provider validation tests (#35471)	2 years ago
Liam Cervante	e704da535e	stack: stacks should be applyable even if no components are (#35498)	2 years ago
Liam Cervante	87bbc47737	stacks: include plan mode in stacks plan format (#35405) ... * stacks: include plan mode in stacks plan format * fix tests * fix missed files	2 years ago
Martin Atkins	170cca1332	stacks+promising: Better error messages for promise resolution failure ... We were previously just treating promising.ErrUnresolved as a singleton that doesn't carry any context along with it. This particular error always represents a bug in the stack runtime rather than a problem with the input, because resolving all of the promises is a key part of the contract for package promising, but it's still helpful to know a little more about what exactly has failed when debugging it. Therefore promising.ErrUnresolved is now a type rather than a value, and its carries with it a set of promise ids that were left unresolved. The stackeval package then recognizes this error type and uses its own records of what each promise was supposed to produce to hopefully return a useful error message that would narrow down what part of the system is buggy. Since this message always reflects a bug in Terraform the error message will probably just be copy-pasted into a bug report, and so this particular diagnostic type (unlike the one we use for promise self-references) only has one presentation form that we use regardless of how many promises we have to return.	2 years ago
Martin Atkins	ec2510fc3d	stacks: Track raw stack as separate messages in raw plan ... Previously we had the entire raw prior state serialized as part of the "plan header" message in the raw plan, which meant that the maximum state size was constrained by the maximum allowed gRPC message size. Instead now we'll use a separate raw plan element for each raw prior state element, so that we're limited only in the size of individual items rather than size of the state as a whole. This deals with the last remaining (non-deprecated) case where our RPC protocol tries to pack an entire raw state or plan into a single protobuf message, and so we're now standardized on using a streaming approach in all cases.	2 years ago
Alisdair McDiarmid	d828776757	stacks+rpcapi: Load prior state and plan separately ... Previously we expected clients to provide an inline raw prior state to PlanStackChanges and an inline raw plan to ApplyStackChanges, which was a simpler design but meant that we might end up generating a state or plan that's too large to be submitted in a single gRPC request, which would then be difficult to resolve. Instead we'll offer separate RPC functions for loading raw state and plan using a gRPC streaming approach, which better mirrors the streaming approach we use to _emit_ these artifacts. Although we don't actually need this benefit right now, this makes it possible in principle for a client that's running PlanStackChanges to feed back the raw planned actions concurrently into OpenPlan and thus avoid buffering the whole plan on the client side at all. This required resolving the pre-existing FIXME about the inconsistency where stackeval wants a raw plan for apply but expects the caller to have dealt with loading the prior state for planning. Here it's resolved in the direction of the caller (rpcapi) always being responsible for loading both artifacts, because that means we can continue supporting the old inline approach for a while without that complexity having to infect the lower layers. Ideally we should remove the legacy approach before this API becomes constrained by compatibility promises, but I've preserved the old API for now to give us some flexibility in when we update the existing clients of this API to use the new approach. Co-authored-by: Martin Atkins <mart@degeneration.co.uk>	2 years ago
Liam Cervante	3ecf7655ba	stacks: insert unknown values for missing outputs during applies (#35463) ... * stacks: insert unknown values for missing outputs during apply operations * fix tests	2 years ago
Daniel Schmidt	1d45d12f40	stacks: track resource deferrals in apply	2 years ago
Daniel Schmidt	591c3dea36	Merge pull request #35433 from hashicorp/TF-10919 ... stacks: add new deferred plan status	2 years ago
Liam Cervante	634155f56b	stacks: extend diagnostic message to capture error from unscheduled component (#35434)	2 years ago
Daniel Schmidt	93cf093168	stacks: add new deferred plan status	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	4f401d9cd3	stacks: add dependency lock to new test case	2 years ago
Daniel Schmidt	bf5037fa05	stacks: add test case	2 years ago
Daniel Schmidt	9f8ab0450c	stacks: fix move apply test	2 years ago
Daniel Schmidt	2a3c579693	stacks: use inspecting phase for provider config tests	2 years ago
Daniel Schmidt	05755422f3	stacks: pass dependency lock in tests	2 years ago
Daniel Schmidt	4433239da4	stacks: validate dependency lockfile in apply phase	2 years ago
Daniel Schmidt	0e5f7acda0	stacks: validate dependency lockfile in planning phase	2 years ago
Daniel Schmidt	fb2f3ca276	stacks: refactor to get dependency locks through main	2 years ago
Daniel Schmidt	2ed6e1facd	stacks: validate lockfile containing all providers ... If the providers are not in the lockfile fetching the schema fails. This leads to follow up diagnostics that send an unclear message. Now we validate the lockfile and if something is missing we skip further validation that relies on the provider schema being present.	2 years ago
Liam Cervante	587a7e88ff	stacks: include move, forget, import counts in apply summaries (#35391)	2 years ago
Liam Cervante	27f26bd1b5	stacks: emit specific moved notification during apply (#35387)	2 years ago
Daniel Schmidt	ae05a0d27b	stacks: use plantimestamp from opts while planning	2 years ago
Daniel Schmidt	a51938c246	stacks: move PlanTimestamp method for consistency	2 years ago
Daniel Schmidt	46999364f0	stacks: refactor for plantimestamp to come from the outside	2 years ago
Daniel Schmidt	49ba330fb5	stacks: force plan timestamp in module runtime	2 years ago
Daniel Schmidt	b62a67394b	stacks: save plantimestamp to plan	2 years ago
Daniel Schmidt	8fa922f912	stacks: implement PlanTimestamp method on ExpressionScope ... This allows us to set the plantimestamp methods value in the stacks language	2 years ago
Mutahhir Hayat	01c5ddaecc	Merge pull request #34797 from hashicorp/mutahhir/stacks/local-value ... stackruntime: Support referencing Local Values within the `tfstacks.hcl` language	2 years ago
Liam Cervante	c0499647fa	stacks: include moved and removed in API (#35360) ... * stacks: include moved and removed in API * fix race test	2 years ago
Mutahhir Hayat	148b19b0d7	return validate value instead of dynamic value	2 years ago
Daniel Schmidt	3aa8e43100	Merge pull request #35356 from hashicorp/b-stacks-apply-variables-not-passed	2 years ago
Martin Atkins	c57f709b1d	stackruntime: Pass the apply-time variable values to stackeval ... This seems to have got lost while resolving some conflicts in 88eec94896. Without this, apply-time input variable values just get ignored entirely and if any are required the plan is not applyable at all. Now we'll pass through what the caller provided so stackeval can validate and use it properly.	2 years ago
Liam Cervante	b646dff26a	stacks: apply nested default values to inputs (#35349) ... * stacks: apply nested default values to inputs * group similar tests	2 years ago
Liam Cervante	284ce63947	stacks: applyable status should be dependent on applyable components (#35350)	2 years ago
Martin Atkins	1714729f87	stackeval: terraform.applying symbol ... 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.	2 years ago
Martin Atkins	e74896bd24	stackruntime: Handle apply-time-specified input variables ... When the topmost stack configuration declares an ephemeral input variable, its values must be provided separately for each of the plan and apply phases. Therefore here we extend the API to allow specifying input variable values during the apply phase, and add rules to check whether all of the apply-time-required input variables have been specified and whether any non-ephemeral variables are either unspecified or re-specified with equal values during the apply phase. This also extends the FindStackConfigurationComponents response to include more metadata about the input variables and output values so that a caller can know which ones are ephemeral. The name of that RPC function had already become a little too specific with the inclusion of embedded stack information and is even moreso now; we might choose to rename it to something more generic like "AnalyzeStackConfiguration" in future, but that'd be a breaking change and therefore requires more coordination.	2 years ago
Martin Atkins	79f78b268f	stackeval: Ephemeral output values ... Now we'll mark the result of an ephemeral output value as ephemeral, and reject attempts to assign any ephemeral values to a non-ephemeral output value.	2 years ago
Martin Atkins	71749d9682	stackeval: Ephemeral input variables ... We'll now handle input variables that are declared as ephemeral = true, and reject attempts to assign ephemeral values to any variables that are not so declared.	2 years ago
Liam Cervante	517f9944f7	stacks: support deferred imports in stacks events (#35334) ... * stacks: support deferred imports in stacks events * fix indentation * fix tests	2 years ago
Liam Cervante	108bd85053	Refactor deferred variable name to defer in terraform1 API (#35343) ... * Refactor deferred variable name to defer in terraform1 API * fix tests	2 years ago
Mutahhir Hayat	d398fa50c6	handle overlooked error in test	2 years ago
Mutahhir Hayat	cb28bf3379	remove unused test	2 years ago