13 Commits (stacks-variable-validations)

Author	SHA1	Message	Date
Daniel Schmidt	c24699eab7	stacks: ensure an empty plan produces a planned status	3 weeks ago
Daniel Schmidt	dce80d4465	stacks: add tests to validate progress events for destroy plans	3 weeks ago
Daniel Schmidt	f4c22be3c5	stacks: send progress events on failed provider configurations	3 weeks ago
Liam Cervante	a80220dcc9	stacks: rename .tfstack files to .tfcomponent (#37013) ... * stacks: rename .tfstack files to .tfcomponent * fix consistency issues	9 months ago
Samsondeen	71dbc7d726	migrate command for terraform stacks (#36482)	11 months 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
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
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	9b95898f63	stacks: emit events for deferred actions (#35325) ... * stacks: emit events for deferred actions * deferral allowed is always on * Update internal/rpcapi/stacks.go Co-authored-by: Daniel Schmidt <danielmschmidt92@gmail.com> --------- Co-authored-by: Daniel Schmidt <danielmschmidt92@gmail.com>	2 years ago
Daniel Schmidt	343f550885	stacks: add inputs to FindStackConfigurationComponents rpc call ... This will allow us to integrate earlier valiation of inputs into the process.	2 years ago
Martin Atkins	97db4b8b12	rpcapi: Opening and closing dependency lock objects ... Currently we only support "opening" a dependency lock object by reading from an existing dependency lock file. In future we might also support mutating dependency lock objects in which case we'd probably also want a "create an empty dependency locks" operation, but we'll wait and see whether we even need that before over-complicating things here.	2 years ago
Martin Atkins	9bd6489dda	rpcapi: Stacks.FindStackConfigurationComponents ... This function returns a summary of the components and embedded stacks declared inside a given stack configuration. This reports only on static information that doesn't require any dynamic evaluation or provider plugin execution, so it should be sufficient to build a skeleton of the UI representing the content of a configuration that can then be populated with dynamic information in later steps, to make the UI feel responsive.	2 years ago
Martin Atkins	72290e1f5c	rpcapi: Management of "handles" ... As with many other systems that involve a client indirectly manipulating objects on the other side of a trust boundary, we're going to use opaque "handles" to represent objects that remain active on the server side between different RPC API calls. A handle is just a 64-bit integer corresponding to an entry in a lookup table maintained by the server, in the "handleTable" type. In the public API we don't make any promises about uniqueness of handles between different types of objects, but to minimize the impact of client bugs we'll internally ensure that we never issue the same handle number for two objects of different types. This means that a client getting their handles mixed up will typically cause an explicit error rather than just doing something weird with an unrelated object that happened to have a matching handle. Our internal API for this will use explicit separate methods for each type of handle and use type parameters so that the Go compiler can call us out if we're inconsistent in how we're using the handles. From a client perspective though these all just layer to protobuf int64; clients might choose to add their own similar abstraction to track handle types, but that's their own business since we can't represent such things efficiently within the protocol buffers schema model. This commit includes initial implementations of Dependencies.OpenSourceBundle and Dependencies.CloseSourceBundle just as some initial evidence that this design works. We'll continue implementing the other real service functions in later commits once the basic infrastructure (like this) is in place.	2 years ago