126 Commits (ae103fc4912d2cf267e8ce89dbd1990a42bebbf4)

Author	SHA1	Message	Date
Daniel Schmidt	97ba67edea	test: ensure ephemeral values are not shown in diagnostics and warning is printed	2 years ago
Radek Simko	06fd817b7c	Remove handling of ephemeral root outputs (#35809) ... * Remove handling of ephemeral root outputs This is effectively reverting ~99% of https://github.com/hashicorp/terraform/pull/35676 The only changes not being reverted are some formatting and deprecation fixes which remain relevant. The code being removed is basically dead code now in the context of root ephemeral outputs being rejected per https://github.com/hashicorp/terraform/pull/35791 * Remove unrelated changes	2 years 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.	2 years ago
James Bardin	16231373a4	update changes in command pkgs	2 years ago
Liam Cervante	3ce9e517ae	fix flaky test in views package (#35469)	2 years ago
Martin Atkins	6f84623cb6	terraform: Initial partial support for ephemeral values ... This is a checkpoint commit on the path to supporting ephemeral values as a cross-cutting concern in the Terraform language. An ephemeral value is one that lives only in RAM during a single phase and so cannot persist from the plan phase to the apply phase, or between consecutive plan/apply rounds. Terraform tracks whether each value is ephemeral using the cty "marks" concept, thus achieving the same dynamic analysis as we already employ for the concept of "sensitive values" that prevents displaying a value in the user interface. This commit is just a starting point which gets some of the basics into place: - input variables and output values can both be statically declared as being ephemeral. Only ephemeral inputs/outputs can have ephemeral values assigned to them, and the recipient of the value sees it as ephemeral even if the assigned value was not already ephemeral. This creates a dynamic analysis cutoff point at module boundaries so that it's possible to determine in isolation whether a single module is using ephemeral values correctly, without having to test it in every possible calling context. - Managed and data resources cannot have ephemeral values assigned into their configurations because Terraform and providers both expect the resource attributes to persist between phases. - Ephemeral values _can_ be used in provider and provisioner configurations, because both of those effectively meet the definition of the new "ephemeral" concept despite it not previously having a name. - Ephemeral markings propagate through all of the built-in language features for dynamic analysis purposes, largely relying on cty's efforts to do that in similar vein as for sensitive marks. In particular, it's possible to define a local value whose expression produces an ephemeral result, and passing ephemeral values to functions should propagate the ephemeral mark to the results when appropriate. (I've not yet thoroughly reviewed all of the built-in functions for correct marks handling though, so there may be some gaps to address in later commits.) The next step for this work will be to change the modules runtime to have support for a workflow involving ephemeral _root_ input variables, where their values must be re-supplied during the apply phase. That will then achieve (in experimental capacity) the first goal of ephemeral values: to be able to provide non-persistent settings such as time-limited API tokens to use in provider configuration blocks.	2 years ago
Brandon Croft	3a5221269b	Revert "Add Warning for Deprecated Modules in `Init` (Second Revision)"	2 years ago
Mark DeCrane	1e7c29243e	Added Extra field for TFC diagnostic processing	2 years ago
Sebastian Rivera	015f795ff0	Rebrand Terraform Cloud to HCP Terraform	2 years ago
UKEME BASSEY	a4415c030a	making json data more useful for client consumption	2 years ago
UKEME BASSEY	7fb13b8868	fixing tests	2 years ago
UKEME BASSEY	c7bbc09631	move all command args from command/init to args/init	2 years ago
UKEME BASSEY	0ea25e3b40	fixing tests internal/command/init, view and argumento	2 years ago
UKEME BASSEY	ea8d0869d8	convert all logs to be view type exclusive for human or json format	2 years ago
UKEME BASSEY	7709db45dc	add init view test	2 years ago
UKEME BASSEY	14c53f74f2	add init view for json and human type view	2 years ago
Martin Atkins	c1342f4f6a	terraform test: Include test case execution time in JUnit XML ... Our currently-experimental JUnit XML output didn't previously include the "time" attribute for test runs at all, but from testing with common JUnit XML consumers we've learned that populating this is effectively mandatory because otherwise software just assumes that it's zero, producing a misleading result. We'll now populate it based on the test runner's measure of the execution time, assuming that the test runner actually measured it. If not, we'll leave it omitted and thus get the same behavior as before, which in practice means that most software will treat it as zero anyway. Because JUnit XML output is still experimental with the goal of getting feedback on exactly how we map the Terraform testing model onto that Java-oriented format, this is intentionally not supported for remote test runs in Terraform Cloud yet. It isn't really practical for Terraform Cloud to participate in short-lived Terraform CLI experiments, because Terraform Cloud has a different release schedule than Terraform CLI does. However, if this experiment is successful then we will eventually need to find a way to plumb this additional information through the JSON logs and ensure that it arrives in the locally-generated JUnit XML output.	2 years ago
Martin Atkins	c8611b51d7	terraform test: JUnit XML output sets testcase classname ... JUnit XML output from "terraform test" is currently experimental, because we're still trying to decide how best to map Terraform's testing concepts onto the Java-oriented JUnit XML format. The first round of feedback showed that some JUnit consumers completely ignore test suite names, and instead expect each test case to specify which "class" it belongs to. Those tools then might allow grouping or filtering the tests by "class". Despite the Java-oriented terminology, it seems that "classname" is really just interpreted something like "test group name", where the classname and the name together represent the full test case identifier. With that in mind then, we'll now duplicate the test suite name (which in our case is the filename of the test scenario file) into the classname attribute of each testcase element. For now we'll retain the per-suite names, always containing the same value, because we also have evidence of some consumers preferring to find this information in that location.	2 years ago
Nick Fagerlund	ccab5f1e55	Rename some UiHook tests for easier ad-hoc runs	2 years ago
Nick Fagerlund	94ea534e40	Refactor terraform.Hook to use a resource-identifying wrapper struct ... The terraform.Hook interface lets other areas of code perform streaming reactions to various events, generally in the service of some UI somewhere. Nearly all of the methods on this interface take an `addrs.AbsResourceInstance` as their first argument, to identify the resource that's being operated on. However, that addrs struct doesn't necessarily contain everything you might want in order to uniquely and usefully identify a resource. It has the module instance and resource instance addresses, but it lacks the provider source address, which can affect how the consuming UI should display the resource's events. (For example, Terraform Cloud wants reliable info about who maintains a given provider, what cloud provider it operates on, and where to find its documentation.) Instead of polluting `addrs.AbsResourceInstance` with extra information that isn't relevant to other call sites, let's change the first argument of each Hook method to be a wrapper struct defined in the package that owns the Hook interface, and add the provider address to that wrapper as a sibling of the resource address. This causes a big noisy commit today, but should streamline future updates to the UI-facing "identity" of a resource; existing callers can ignore any new fields they're uninterested in, or exploit new info as needed. Other than making new information available for future edits to Hook implementing types, this commit should have no effect on existing behavior.	2 years ago
Nick Fagerlund	d81a546e55	Lints: hook_count_test, "redundant type from slice composite literal" ... I was in the file for other reasons, and wanted to reduce noise in my editor.	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
Martin Atkins	884e1fb2a4	terraform: Plans can be "complete" and "applyable" ... These ideas are both already implied by some logic elsewhere in the system, but until now we didn't have the decision logic centralized in a single place that could therefore evolve over time without necessarily always updating every caller together. We'll now have the modules runtime produce its own boolean ruling about each characteristic, which callers can rely on for the mechanical decision-making of whether to offer the user an "approve" prompt, and whether to remind the user after apply that it was an incomplete plan that will probably therefore need at least one more plan/apply round to converge. The "Applyable" flag directly replaces the previous method Plan.CanApply, with equivalent logic. Making this a field instead of a method means that we can freeze it as part of a saved plan, rather than recalculating it when we reload the plan, and we can export the field value in our export formats like JSON while ensuring it'll always be consistent with what Terraform is using internally. Callers can (and should) still use other context in the plan to return more tailored messages for specific situations they already know about that might be useful to users, but with these flags as a baseline callers can now just fall back to a generic presentation when encountering a situation they don't yet understand, rather than making the wrong decision and causing something strange to happen. That is: a lack of awareness of a new rule will now cause just a generic message in the UI, rather than incorrect behavior. This commit mostly just deals with populating the flags, and then all of the direct consequences of that on our various tests. Further changes to actually make use of these flags elsewhere in the system will follow in later commits, both in this repository and in other repositories.	2 years ago
Martin Atkins	89a53e9105	command/test: Fix invalid XML processing instruction ... Annoyingly, I seem to have flubbed this slightly while I was adapting to use enc.EncodeToken instead of (as originally written) just writing the literal processing instruction bytes onto the front of the buffer directly. This made the output invalid for any XML processor that interprets the special "xml" processing instruction. It'll now be valid again.	2 years ago
Martin Atkins	4a0d06c13e	terraform test: Report skipped runs in JUnit XML output ... Previously we were just ignoring skipped runs completely, but JUnit XML has some elements/attributes for describing those and so we'll populate those too now.	2 years ago
Martin Atkins	b43ddd8ff6	terraform test: Experimental JUnit XML reporting ... This adds an experimental new option -junit-xml=FILENAME for the "terraform test" command. When specified, it writes a JUnit XML report to the specified filename once the test run is complete, while continuing to report test progress in the UI in the usual way. This is only experimental for now because it remains to be seen if this particular mapping to the JUnit XML schema is actually useful in real software -- this format is woefully underdocumented and implemented slightly differently by each consumer -- and so we might change this significantly before stabilizing it, or remove it altogether if it turns out that there's no useful mapping to JUnit XML here. Hopefully those who are interested in JUnit XML reports will try this experiment against their favorite JUnit XML-consuming software and report back whether the report is presented in a helpful way. It's a de-facto convention for JUnit XML to be reported separately to a file, rather than replacing the normal test run output, since tools that consume this format tend to present its results in a separate and less prominent place than the output of the command itself. This option is designed to follow that convention for consistency with various other software that produces this format. The implementation here is intentionally pretty minimal and simplistic just as a starting point for gathering feedback. The main priority is that it be easy to evolve this based on feedback and to remove it altogether if we decide not to stabilize this at all. If this does become stabilized, it might deserve being factored out into a separate package so that we can minimize the amount of logic embedded directly inside the views package, and it will certainly need some unit tests to represent what we've committed to supporting in future versions.	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
Martin Atkins	0811395e6f	states: State.AllResourceInstanceObjectAddrs should say "Managed" ... This method used the more appropriate name AllManagedResourceInstanceObjectAddrs in its docstring, but was incorrectly named just AllResourceInstanceObjectAddrs in its actual definition, obscuring the fact that it filters out everything except objects from managed resources. Now we'll use the originally-documented name to make this clearer. This also factors out the implementation into a separate unexported function that takes the filtering criteria as an argument, since in future commits we're going to add other variations of this which return different subsets of the resource instance objects in the state.	2 years ago
Martin Atkins	ac562eeb6f	states: State.AllResourceInstanceObjectAttrs returns a set ... Originally we had this function returning a slice of an anonymous struct type because we hadn't yet recognized "resource instance object" as a first-class address type. We do now have addrs.AbsResourceInstanceObject to represent that sort of thing, and so we'll use that here. This also means we can return a set of addresses rather than a slice, which is semantically better as this set of addresses is not inherently ordered. Some existing callers were depending on the sort.SliceStable we were originally doing to make the result dependable, and so now we have a generic helper for turning addrs.Set into a sorted slice of the same type using our address types' "Less" methods that describe their natural or preferred ordering.	2 years ago
Martin Atkins	13e26b60dd	addrs: Adopt DeposedKey as an address type; remove states.Generation ... Previously we had states.DeposedKey as our representation of the unique keys used to differentiate between multiple deposed objects on the same resource instance. That type is useful in various places, but its presence in the "states" package made it troublesome to import for some callers. Since its purpose is as an identifier, this type is more at home in the "addrs" package. The states package retains a small number of aliases to preserve compatibility with a few existing callers for now, until we have the stomach for a more invasive change. This also removes the largely-redundant states.Generation interface type, which initially was intended as a way to distinguish between "current" objects and deposed objects, but didn't really add anything because we already have addrs.NotDeposed to represent that situation. Instead, we just ended up with various bits of boilerplate adapter code converting between the two representations. Everything now uses addrs.DeposedKey and uses addrs.NotDeposed to identify non-deposed objects.	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	3 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	3 years ago
Liam Cervante	91d26b6ea6	Refactor file and run block feedback frequency (#33840) ... * Refactor file and run block feedback frequency * fix consistency checks * make generate	3 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
Liam Cervante	9bc5c7afbb	Include run block for JSON fatal interrupt test summaries (#33720)	3 years ago
CJ Horton	98b81d3c50	add missing copyright headers	3 years ago
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
Liam Cervante	f1ca74f09f	Update JSON_UI_VERSION after test framework changes	3 years ago
Liam Cervante	4560a83721	test framework: include transformed config before validating config (#33608)	3 years ago
Sebastian Rivera	08e58fd484	Fix saved plan test regressions, fixtures	3 years ago
Nick Fagerlund	ed27fa096e	command/views/show_test: Update method arguments, add test cases	3 years ago
Nick Fagerlund	3a9ce2afb1	Update show command and view to support inspecting cloud plans ... One funny bit: We need to know the ViewType at the point where we ask the Cloud backend for the plan JSON, because we need to switch between two distinctly different formats for human show vs. `show -json`. I chose to pass that by stashing it on the command struct; passing it as an argument would also work, but one, the argument lists in these nested method calls were getting a little unwieldy, and two, many of these functions had to be receiver methods anyway in order to call methods on Meta.	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
Liam Cervante	ad26644578	Fix flaky test in views package (#33560)	3 years ago
Liam Cervante	c91f91cc9e	testing framework: change test file extension to .tftest.hcl (#33553)	3 years ago
Liam Cervante	ca85d3bf85	Implement word wrapping in the terraform test view functions (#33547) ... * Implement word wrapping in the terraform test view functions * Update internal/command/views/test.go Co-authored-by: CJ Horton <17039873+radditude@users.noreply.github.com> --------- Co-authored-by: CJ Horton <17039873+radditude@users.noreply.github.com>	3 years ago
Liam Cervante	6c7db16566	testing framework: refactor interrupt logic for immediate exits (#33532) ... * testing framework: refactor interrupt logic * fix formatting	3 years ago
Liam Cervante	6882dd9530	testing framework: introduce test command optional flags (#33504) ... * testing framework: introduce test command optional flags * address consistency checks	3 years ago
Liam Cervante	4862812c94	testing framework: introduce interrupts for stopping tests (#33477) ... * [testing framework] prepare for beta phase of development * [Testing Framework] Add module block to test run blocks * [testing framework] allow tests to define and override providers * testing framework: introduce interrupts for stopping tests * remove panic handling, will do it properly later	3 years ago