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.
* 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>
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.
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.
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.
