terraform

Commit Graph

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	7e3d300670	Go formatting	1 month ago
Mutahhir Hayat	d653c99eda	Add action invocation to the actual planned changes for the component	1 month ago
Mutahhir Hayat	a876afb6ca	Send ActionInvocation counts in component report	1 month ago
Radek Simko	0fe906fa8c	make copyrightfix	2 months ago
Liam Cervante	fbd5a7930e	stacks: allow removed blocks to target components in nested stacks (#36787 ) * stacks: allow removed blocks to target components in nested stacks * make copywrite fix * fix comments	1 year 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
Daniel Schmidt	93cf093168	stacks: add new deferred plan status	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
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
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	2559151d0a	stackruntime: Count actions successfully applied Callers expect to be given an updated set of counts for how many of each action were completed, which we'll achieve by having the terraform.Hook implementation keep track of those and then announce them based on what it collected. We can't use the plan for this directly because terraform.Context.Plan seems to modify the plan it's given during its work, and on success the plan ends up being totally empty.	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
Martin Atkins	8af46fd38b	stackruntime: An extensible "hooks" API Following a similar model that we've previously used in other parts of Terraform to expose UI-oriented progress events, here we define stackruntime.Hooks as a collection of optional callbacks a caller can use to subscribe to events, and the supporting utility code to help us concisely and correctly call those hook functions from the main evaluation code without adding too much extra noise to the code. Although the primary focus of this API is driving realtime UI updates, the API design also aims to accommodate distributed tracing use-cases by allowing callers to propagate arbitrary values between related event notifications and to inject additional values into the context.Context used for downstream operations that might not be under the direct supervision of stackruntime/stackeval.	2 years ago

22 Commits (main)