terraform

Commit Graph

Author	SHA1	Message	Date
Samsondeen	c0a7ff235b	Apply some new go collection features (#36818 )	11 months ago
Daniel Schmidt	fec6e4b552	send resource identities to provider calls	12 months ago
Daniel Banck	10c9b64007	Rename schema.Block to Body (#36629 )	12 months ago
Radek Simko	289a3568da	Address `go vet` 1.24 failures (#36485 ) * address go vet failures * avoid unnecessary .Error()	1 year ago
Daniel Schmidt	276662f754	ephemeral: add test case for block rendering	1 year ago
Liam Cervante	672cd816d5	don't precompute actions	1 year ago
Daniel Schmidt	0e6a3ac994	ephemeral: render write-only attributes in plan UI	1 year ago
Radek Simko	0a266c88c4	terraform: Emit lifecycle phases of ephemeral resources to the UI (#35919 )	1 year ago
Liam Cervante	332757894d	plan renderer: fix crash when updating a null attribute to unknown (#35709 )	1 year ago
Liam Cervante	abd6b9ef1b	plan renderer: render unknown nested blocks properly (#35644 )	1 year ago
kmoe	a2039517a5	states: store ephemeral output values in memory (#35676 ) Ephemeral root output values must be kept in the in-memory state representation, but not written to the state file. To achieve this, we store ephemeral root outputs separately from non-ephemeral root outputs, so Terraform can access them during a single plan or apply phase. Ephemeral root outputs always have a value of null in the state file. This means that the "terraform output" command, that reads the state file, reports null values for these outputs. Consumers of 'terraform output -json' should use the presence of '"ephemeral": true' in such output to interpret the value correctly.	1 year ago
James Bardin	16231373a4	update changes in command pkgs	2 years ago
Daniel Schmidt	3b95a5f6b1	fix formatting Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com>	2 years ago
Daniel Schmidt	8e1f02843d	jsonformat: update tests	2 years ago
Daniel Schmidt	b9933789aa	jsonformat: render deferred diff with no current changes message	2 years ago
Daniel Schmidt	c619cd2536	improve wording Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com>	2 years ago
Daniel Schmidt	a00e015e24	jsonformat: render different no changes message on deferred actions	2 years ago
Daniel Schmidt	4afb3b2b48	jsonformat: render deferred actions	2 years ago
James Bardin	6b19b9e82a	render entirely unknown blocks in the plan output The plan renderer was missing a check for entirely unknown blocks, causing them to be omitted from the human readable output. An unknown block can happen when using an unknown for_each value in a dynamic block assignment.	2 years ago
Sebastian Rivera	015f795ff0	Rebrand Terraform Cloud to HCP Terraform	2 years ago
Martin Atkins	30e2fd6525	Handle marks a little more consistently In the very first implementation of "sensitive values" we were unfortunately not disciplined about separating the idea of "marked value" from the idea of "sensitive value" (where the latter is a subset of the former). The first implementation just assumed that any marking whatsoever meant "sensitive". We later improved that by adding the marks package and the marks.Sensitive value to standardize on the representation of "sensitive value" as being a value marked with _that specific mark_. However, we did not perform a thorough review of all of the mark-handling codepaths to make sure they all agreed on that definition. In particular, the state and plan models were both designed as if they supported arbitrary marks but then in practice marks other than marks.Sensitive would be handled in various inconsistent ways: dropped entirely, or interpreted as if marks.Sensitive, and possibly do so inconsistently when a value is used only in memory vs. round-tripped through a wire/file format. The goal of this commit is to resolve those oddities so that there are now two possible situations: - General mark handling: some codepaths genuinely handle marks generically, by transporting them from input value to output value in a way consistent with how cty itself deals with marks. This is the ideal case because it means we can add new marks in future and assume these codepaths will handle them correctly without any further modifications. - Sensitive-only mark preservation: the codepaths that interact with our wire protocols and file formats typically have only specialized support for sensitive values in particular, and lack support for any other marks. Those codepaths are now subject to a new rule where they must return an error if asked to deal with any other mark, so that if we introduce new marks in future we'll be forced either to define how we'll avoid those markings reaching the file/wire formats or extend the file/wire formats to support the new marks. Some new helper functions in package marks are intended to standardize how we deal with the "sensitive values only" situations, in the hope that this will make it easier to keep things consistent as the codebase evolves in future. In practice the modules runtime only ever uses marks.Sensitive as a mark today, so all of these checks are effectively covering "should never happen" cases. The only other mark Terraform uses is an implementation detail of "terraform console" and does not interact with any of the codepaths that only support sensitive values in particular.	2 years ago
Liam Cervante	924958bce0	plan renderer: ensure JSON strings are completely JSON (#34959 )	2 years ago
James Bardin	bdd5a2cd33	try to render some empty string -> null changes Changes between empty strings and `null` were hidden in the CLI output, because the SDK could not reliably detect the difference and may return either value depending on the situation. This legacy behavior can be confusing for authors of new provider which can correctly handle `null`, and it would be preferable to be able to render those changes in the CLI. While we don't have enough information to detect when the legacy behavior is required, we can detect a number of cases where it's certain that we are not dealing with a legacy schema and should output the full diff.	2 years ago
Liam Cervante	82361afd73	plan rendering: fix truncation of very large numbers (#34702 )	2 years ago
Daniel Schmidt	adf008d489	adjust tests to new implementation	2 years ago
Daniel Schmidt	19f9bdac14	handle multi-line string diffs correctly	2 years ago
Daniel Schmidt	a64df71152	fix comment	2 years ago
Daniel Schmidt	1531fee472	clarify comment	2 years ago
Daniel Schmidt	2a625b75a4	handle reordering explicitly	2 years ago
Daniel Schmidt	31bd2b5be0	plan: compare individual elements if list is same length Closes #33779	2 years ago
Liam Cervante	f0b61090a2	Move the testing MockProvider into a dedicated shared package (#34681 ) * move the testing MockProvider into a dedicated shared package * address comments * fix new changes	2 years ago
kmoe	8f3aa0e099	jsonformat: render forget-only attr changes as no-op (#34403 ) * jsonplan: document forget actions * jsonformat: format forget changes as no-op Previous to this commit, forget-only actions (i.e. "forget", not "create then forget") would be rendered using the forget action symbol for the top-level resource, and the delete action symbol for each resource attribute, with a new value of "null". This attribute rendering is identical to that for resource deletion, which might suggest to some users that Terraform plans to delete the resource, not just remove it from state. This commit tweaks the renderer so forget-only changes render as no-ops but with the forget action symbol and resource change comment.	2 years ago
Martin Atkins	17f420102f	states: Local values no longer live in state Back when we added local values (a long time ago now!) we put their results in state mainly just because it was the only suitable shared data structure to keep them in. They are a bit ideosyncratic there because we intentionally discard them when serializing state to a snapshot, and that's just fine because they never need to be retained between runs anyway. We now have namedvals.State for all of our named value result storage needs, so we can remove the local-value-related fields of states.Module and use the relevant map inside the local value state instead. As of this commit, states.State now tracks only the data that we actually persist between runs in state snapshots, which will hopefully avoid future bugs resulting from the former difference in fidelity between a freshly-created in-memory state vs. one loaded from a snapshot.	2 years ago
Martin Atkins	b0b8d4aa6f	states: Only track root module output values For a very long time we've had an annoying discrepancy between the in-memory state model and our state snapshot format where the in-memory format stores output values for all modules whereas the snapshot format only tracks the root module output values because those are all we actually need to preserve between runs. That design wart was a result of us using the state both as an internal and an external artifact, due to having nowhere else to store the transient values of non-root module output values while Terraform Core does its work. We now have namedvals.State to internally track all of the throwaway results from named values that don't need to persist between runs, so now we'll use that for our internal work instead and reserve the states.State model only for the data that we will preserve between runs in state snapshots. The namedvals internal model isn't really designed to support enumerating all of the output values for a particular module call, but our expression evaluator currently depends on being able to do that and so we have a temporary inefficient implementation of that which just scans the entire table of values as a stopgap just to avoid this commit growing even larger than it already is. In a future commit we'll rework the evaluator to support the PartialEval mode and at the same time move the responsiblity for enumerating all of the output values into the evaluator itself, since it should be able to determine what it's expecting by analyzing the configuration rather than just by trusting that earlier evaluation has completed correctly. Because our legacy state string serialization previously included output values for all modules, some of our context tests were accidentally depending on the implementation detail of how those got stored internally. Those tests are updated here to test only the data that is a real part of Terraform Core's result, by ensuring that the relevant data appears somewhere either in a root output value or in a resource attribute.	2 years ago
kmoe	a718f70f85	Add removed block (#34251 ) * terraform: remove redundant code NodeDestroyResourceInstance is never instantiated with a DeposedKey of anything other than states.NotDeposed, so the deleted code is never run. Deposed objects get a NodeDestroyDeposedResourceInstanceObject instead. * tfdiags: add helper func * configs: introduce removed block type * terraform: add forget action * renderer: render forget actions * terraform: deposed objects can be forgotten Deposed objects encountered during planning spawn NodePlanDeposedResourceInstanceObject, which previously generated a destroy change. Now it will generate a forget change if the deposed object is a forget target, and a destroy change otherwise. The apply graph gains a new node type, NodeForgetDeposedResourceInstanceObject, whose execution simply removes the object from the state. * configs: add RemoveTarget address type * terraform: modules can be forgotten * terraform: error if removed obj still in config * tests: better error on restore state fail * Update CHANGELOG.md	2 years ago
Liam Cervante	01c0480e77	Test framework will produce regular updates in -json mode (#33953 ) * Test framework will produce regular updates in -json mode * add tests * docs * docs tweaking	2 years ago
Liam Cervante	ffbcaf8bef	Implement TFC integration for private module registry test runs (#33710 ) * implement module testing via TFC * ready for review * fix static checks * licence headers	2 years ago
Liam Cervante	487eeda94e	[testing framework] Add documentation (#33454 ) * [terraform test] add docs * Apply suggestions from code review Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com> * polish remaining comments * Apply suggestions from code review Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com> * address remaining comments * typo * update verbose machine readable docs * standardise new JSON field names --------- Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>	3 years ago
Liam Cervante	2ea141b3f4	Embed the schemas directly in the testing framework JSON verbose outputs (#33755 )	3 years ago
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
Nick Fagerlund	0df3c143bb	New plans.Quality type for display-relevant facts about a plan This commit replaces the existing jsonformat.PlanRendererOpt type with a new type with identical semantics, located in the plans package. We needed to be able to exchange the facts represented by `jsonformat.PlanRendererOpt` across some package boundaries, but the jsonformat package is implicated in too many dependency chains to be safe for that purpose! So, we had to make a new one. The plans package seems safe to import from all the places that must emit or accept this info, and already contains plans.Mode, which is effectively a sibling of this type.	3 years ago
James Bardin	cf5ebaf685	s/Schemas/ProviderSchema/	3 years ago
James Bardin	36d34135ad	replace remaining types in tests	3 years ago
Liam Cervante	3613e972c5	Plan renderer: Support users indexing integer paths with stringified numbers (#33475 )	3 years ago
kmoe	b4d1146f58	plannable import: improve gen config human plan output (#33194 ) * renderer: remove hard-coded config gen path * mention config gen file in plan next steps	3 years ago
Liam Cervante	4d837df546	Plannable import: Add generated config to JSON and human-readable plan output (#33154 ) * command: keep our promises * remove some nil config checks Remove some of the safety checks that ensure plan nodes have config attached at the appropriate time. * add GeneratedConfig to plan changes objects Add a new GeneratedConfig field alongside Importing in plan changes. * add config generation package The genconfig package implements HCL config generation from provider state values. Thanks to @mildwonkey whose implementation of terraform add is the basis for this package. * generate config during plan If a resource is being imported and does not already have config, attempt to generate that config during planning. The config is generated from the state as an HCL string, and then parsed back into an hcl.Body to attach to the plan graph node. The generated config string is attached to the change emitted by the plan. * complete config generation prototype, and add tests * Plannable import: Add generated config to json and human-readable plan output --------- Co-authored-by: Katy Moe <katy@katy.moe>	3 years ago
hashicorp-copywrite[bot]	bb36298b21	[COMPLIANCE] Add Copyright and License Headers	3 years ago
Liam Cervante	77f10c4f68	Imports should come before Adds in change summaries (#33147 )	3 years ago
Liam Cervante	54c1c1162f	[Plannable Import] Implement human-readable plan rendering (#33113 ) * [plannable import] embed the resource id within the changes * add the plannable imports to the json and human plans * latest importing struct	3 years ago
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago

1 2

94 Commits (9212a2efddbb04069009d5e03eefa366944f013f)