14 Commits (main)

Author	SHA1	Message	Date
Roniece	5e32bf2cdc	Add trigger information to action invocation status and progress ... Include the action trigger (lifecycle or invoke) in ActionInvocationStatus and ActionInvocationProgress messages to uniquely identify action invocations triggered by different events. Additional context: https://github.com/hashicorp/terraform/pull/38051#discussion_r2812460131	4 weeks ago
Roniece	e4f849db4a	Add ActionInvocationProgressHookData type	4 weeks ago
Roniece	6f9f82e5c5	Test hooks + add generated code	4 weeks ago
Mutahhir Hayat	d653c99eda	Add action invocation to the actual planned changes for the component	1 month ago
Radek Simko	0fe906fa8c	make copyrightfix	2 months ago
James Bardin	3b3e4bf003	update the rest of the go:generate calls	1 year 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	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
Nick Fagerlund	7703a5aead	Stacks: Add ProviderAddr field to ResourceInstanceStatusHookData ... This updates the stackruntime `hooks.ResourceInstanceStatusHookData` struct to include the provider address, and updates everything that instantiates that struct to pass along the valid provider address it received from its own caller. In other words, this commit is a bridge between the terraform.Hook interface methods (which already have access to the provider address) and the stacks hook callbacks that result in RPC messages being sent to the agent.	2 years ago
Martin Atkins	5372d5eb98	stacks+rpcapi(stacks): Model deposed objects for resource instances ... Previously we incorrectly assumed that resource instances only have one "current" object each. However, resource instances can also have deposed objects which we must also keep track of. This is a breaking change to the rpcapi since we're now using a new message type for a resource instance _object_ address in several places. That breakage is intentional here because at the time of writing this commit the rpcapi is not yet in any stable release and we want to force updating our existing internal client to properly handle deposed objects too.	2 years ago
Martin Atkins	947c483c49	rpcapi: Stack plan and apply use the same progress message type ... Previously we had the progress messages directly inlined as events of the PlanStackChanges operation, but that means that there's no common interface type for progress events across both the plan and apply phases, making it hard for Go implementations to share marshaling code between the two phases. Now we'll use a new StackChangeProgress message type to contain all of the progress message situations. This makes constructing and using the progress messages a little more verbose -- an extra layer of message -- but means that we can write code that works generically with the StackChangeProgress generated struct and thus share it between the two phases, leading to less code overall. As of this commit we don't yet have the apply phase generating any progress messages, but we'll extend it in a subsequent commit now that it's possible to share more of that event-generating code between the two phases.	2 years ago
Martin Atkins	d1b0632e82	stackruntime: Add HashiCorp copyright comments	2 years ago
Alisdair McDiarmid	927350eca8	rpcapi: Add component expansion and change summary ... We want to report the result of component expansion to the client as early as possible, so that it can prepare to receive any following information for each instance. This message is critical when a component's expansion expression evaluates to an empty set: without this message's confirmation of this case, it will be unable to determine that the component will receive no plans for any instances until the plan completes. We also want to report a roll-up of the resource changes upon completion of each component's plan and apply operations, so that a client can summarize the operation changes without performing the roll-up operation on all received change events.	2 years ago
Alisdair McDiarmid	54062a52cb	stacks: More extensive in-progress plan events ... Expand the existing hooks to emit events throughout the planning process, providing enough information for the Terraform Cloud UI to render a live-updating representation of the plan. We also sketch out the equivalent hooks for the apply operation.	2 years ago