758 Commits (a8b126aeffdd1876da51e59a7cc685ad030e86d3)

Author	SHA1	Message	Date
James Bardin	2ffbd0eb4e	remove old refactoring comments	2 years ago
James Bardin	0b8fbfe323	ignore unexported state field in comparison ... and unify the options used to compare changes in tests	2 years ago
James Bardin	16231373a4	update changes in command pkgs	2 years ago
James Bardin	bc750192e4	POC for always using decoded changes in core ... We should not need to encode and decode change values within core, since the encoded version is only technically needed for serialization. This pattern stems from the conversion to current changes system, but back then we did not have easy access to the correct schemas at the time to encode and decode the entire set of changes. Moving the core handling of changes to only use the decoded values will drastically improve evaluation efficiency, removing a round trip through encoded values for every resource reference.	2 years ago
James Bardin	04b442d419	allow slashes in git url parameters ... Git url refs often contain slashes, which were incorrectly being split and appended to the path as a go-getter subdir.	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
Liam Cervante	471bddf3ba	json plan: update resource index and import ids to support unknown values (#35518)	2 years ago
Liam Cervante	4f62fcac53	init: fix invalid + duplicate required provider blocks crashing (#35533)	2 years ago
Liam Cervante	3ce9e517ae	fix flaky test in views package (#35469)	2 years ago
James Bardin	fcfbd85aa5	add suggestion to run `terraform providers` ... On a default provider install failure we can always suggest running `terraform providers` to help in cases where it's not apparent to the user how to proceed. This would most commonly be encountered by conflicting provider requirements, but if we find there are other common situations we may want to generate a more precise error type for better diagnostics.	2 years ago
Niklas Rosenstein	50463774b0	Fix and clarify error message when -plugin-dir can't be saved to workspace directory	2 years ago
Martin Atkins	71d14e78fd	lang: Experimental "ephemeralasnull" function ... This is another part of the existing ephemeral_values experiment, taking a value of any type that might have ephemeral values in it and returning a value of the same type which has any ephemeral value replaced with a null value. The primary purpose of this is to allow a module to conveniently return an object that would normally contain nested ephemeral values -- such as an instance of a managed resource type that has a write-only attribute -- through an output value that isn't declared as ephemeral. This would then expose all of the non-ephemeral parts of the object but withhold the ephemeral parts. In the case of write-only attributes, it exposes the normal attributes while withholding the write-only ones. The name of this function could potentially change before stabilization, because it's quite long and clunky. I did originally consider "nonephemeral" to match with the existing "nonsensitive", but that didn't feel right because "nonsensitive" removes the sensitive mark while preserving the underlying value while this function removes the mark and the real value at the same time. (It would not be appropriate to have a function that just removes the ephemeral mark while preserving the value, because correct handling of ephemerality is important for correctness while sensitivity is primarily a UI concern so we don't need to be quite so picky about it.)	2 years ago
James Bardin	3bf06b18fc	update helptext and docs	2 years ago
James Bardin	3875ea3656	add -lock-file flag to providers mirror command ... The providers mirror command was updated to inspect the lock file, however that was not part of the original intent for the command, and it's possible that the command needs to be run without a lock file. Since we have been honoring the lock file for the past few releases, let's keep that consistent and allow disabling the file with `-lock-file=false`.	2 years ago
James Bardin	e57d8add35	Check lock file diags in mirror command ... The lock file diagnostic were not being checked in the mirror command, so an incomplete or broken lock file might cause the cli to crash.	2 years ago
Martin Atkins	9dd16a7fba	command: "terraform apply" accepts variable values with saved plan ... To support ephemeral values we need a more complicated set of rules about what input variables can and must be set when applying a saved plan. The command itself does not have enough information to implement those rules itself, so we'll let them pass through and check this in the local backend's apply phase instead. The local backend's apply phase already had basic support for dealing with apply-time variable values, but it'll now also be responsible for rejecting attempts to set variables when the experiment isn't enabled, to keep all of this logic in roughly the same place.	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
James Bardin	a38be7d174	Merge pull request #35271 from hashicorp/jbardin/render-uknown-block ... render entirely unknown blocks in the plan output	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
Brandon Croft	3a5221269b	Revert "Add Warning for Deprecated Modules in `Init` (Second Revision)"	2 years ago
kmoe	1e2d4a2ecc	lang: stabilise templatestring func experiment (#35224) ... * lang: stabilise templatestring func experiment * command/jsonfunction: marshal templatestring * docs: add templatestring	2 years ago
Mark DeCrane	4bd790d8a4	Merge pull request #35231 from hashicorp/TF-12601/deprecated-module-version-warns-rev2 ... Add Warning for Deprecated Modules in `Init` (Second Revision)	2 years ago
MicahKimel	3258744166	Remove invalid warning during cleanup phase (#35172) ... * stop invalid warning during cleanup phase * stop invalid warning during cleanup phase * invalid warning during cleanup phase * remove unwanted comment * update GetVariables parameter for including warnings * invalid warning during cleanup phase test case * update invalid warnings in cleanup test case to throw a warning for the validation variable before cleanup phase * remove unwanted warnings	2 years ago
Mark DeCrane	1e7c29243e	Added Extra field for TFC diagnostic processing	2 years ago
Sebastian Rivera	7012371d1f	Merge pull request #35176 from hashicorp/sebasslash/tf-15302_modifiable-snapshot-interval ... Add `TF_STATE_PERSIST_INTERVAL` environment variable.	2 years ago
Sebastian Rivera	52c7dfceb4	Add unit tests for state persist interval env var	2 years ago
Sebastian Rivera	a72d02135b	Define StatePersistInterval as command meta field	2 years ago
Liam Cervante	48fc2d3ac7	terraform test: Disallow version constraints within test files (#35161)	2 years ago
Brandon Croft	716fcce239	chore: add command ctx to GetRootOutputValues	2 years ago
Liam Cervante	b718c55b13	deferred actions: include deferred resources within JSON plan output (#35065) ... * deferred actions: include deferred resources within JSON plan output * address comments	2 years ago
Liam Cervante	14418bd198	terraform test: move override evaluation into expander (#35030) ... * terraform test: move override evaluation into expander * clarify comment	2 years ago
Nick Fagerlund	40b6f21b3d	Merge pull request #35050 from hashicorp/rebrand-hcp-terraform ... Rebrand Terraform Cloud to HCP Terraform	2 years ago
Sebastian Rivera	c04d32dc26	Inject appname to backend migration prompts	2 years ago
Sebastian Rivera	015f795ff0	Rebrand Terraform Cloud to HCP Terraform	2 years ago
Liam Cervante	448775102c	terraform test: Push evaluation of variables to as late as possible (#35014) ... * terraform test: Push evaluation of variables to as late as possible * Update internal/moduletest/hcl/variable_cache.go Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com> * address comments --------- Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com>	2 years ago
Liam Cervante	6963c54bec	terraform test: don't remove sensitive marks from inputs (#35021)	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
Martin Atkins	5a944133e6	command/jsonstate: Reject unsupported marks ... Our JSON state format has support for sensitive marks in particular but lacks generalized support and so cannot deal with any other marks. Previously it just assumed that any mark must be the sensitive mark, but now we'll reject other marks to ensure that if any new marks are added we must consider whether and how the JSON state format should handle them.	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	ce7824f905	add interrupt error to the diags so each component becomes responsible for rendering the errors	2 years ago
UKEME BASSEY	0ea25e3b40	fixing tests internal/command/init, view and argumento	2 years ago
UKEME BASSEY	ba8386b8a2	json does not support interactive prompt so dont allow setting of both -migrate-state and -json options	2 years ago
UKEME BASSEY	ea8d0869d8	convert all logs to be view type exclusive for human or json format	2 years ago
UKEME BASSEY	370a471ecb	fix json -help display and failing tests	2 years ago
UKEME BASSEY	26f01d699a	add test for -json support	2 years ago
UKEME BASSEY	a3f3b64e4c	add -json to tf init	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
Liam Cervante	924958bce0	plan renderer: ensure JSON strings are completely JSON (#34959)	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
Martin Atkins	14b08c3745	terraform: Move variable validation into its separate node type ... The parent commit added a new node to the graph for each existing input variable node, but that node didn't do anything yet. Now those new nodes are actually responsible for checking the variable's validation rules, instead of that being included in the same graph node that decides the variable's final value. This also refines the validation node graph transformer to only insert a validation node if there's at least one rule to check, which should avoid bloating the graph for anyone who isn't actually using input variable validation. Therefore the plan graph builder tests revert back to their old expected result because that input configuration does not include any validation rules. For the moment this just moves around functionality that already existed and doesn't add anything new, but having the validation handled in a separate graph node means that we can evaluate the validation rules in the EvalContext of the module where the variable was declared instead of where it was defined, and so a future commit will allow -- initially just as an experiment -- validation rules that can refer to other objects in the module where the variable is declared, including the values of other input variables. As a nice bonus, this fixed a small bug in "terraform test" where problems with variable values defined in the test run were reported as problems with the variable declaration, rather than with the expression assigning the value to it. Since it's now NodeRootVariable that decides the definition source range, rather than the validation-rule-checking helper, it has access to the source range provided in a terraform.InputValue object, which was already populated correctly for per-test-run definitions.	2 years ago
Nick Fagerlund	dc9a13a975	Catch a missing err check in apply command ... Plan and refresh already had this, but apply would deref a nil opReq and panic.	2 years ago
Nick Fagerlund	1781c8e8e9	Experimental `-allow-deferral` flag for enabling deferred actions on CLI ... Now that deferred actions is a top-level per-plan option, here's a lil command-line option for turning it on! - It's called `-allow-deferral`. - It is ONLY legal to use if this is an experimental build, i.e. compiled with `go build -ldflags "-w -s -X 'main.experimentsAllowed=yes'"` or the like. Implementation notes: The design constraint here was, "please avoid having to change the build infrastructure or alter the function of every args parsing function". So, since `extendedFlagSet()` doesn't have access to the var that says we're in an experimental build, I had to move the validation for that particular flag to later in the process, when we're building the operation request.	2 years ago
Craig Sloggett	f20b055618	Prevent duplicate error messages for unset environment variables ... Track and report each unset environment variable only once, even if it's referenced multiple times in the Terraform configuration.	2 years ago
Craig Sloggett	b53db4ef14	Ensure environment variables are set when interpolating rawPath	2 years ago
Craig Sloggett	302c6deddc	Interpolate environment variables when configuring dev_overrides	2 years ago
Martin Atkins	58b48f4bab	provider/terraform: Use new convention for function names ... When we added these functions we hadn't yet settled on a single convention for how provider-contributed functions ought to be named, and so these followed the convention previously used for Terraform's own built-in functions. We've now decided to use the new provider namespace as an opportunity to partially fix the historical design error of naming functions as all lowercase without any separation between words. This makes the provider functions inconsistent with the built-in functions, but should at least hopefully encourage the provider functions to be consistent with one another, so that the rule for which to use is relatively easy to remember. This also switches the word order because the provider functions convention prefers the verb to come first: encode_tfvars instead of tfvarsencode.	2 years ago
Martin Atkins	dbde17b535	terraform console: Multi-line entry support ... The console command, when running in interactive mode, will now detect if the input seems to be an incomplete (but valid enough so far) expression, and if so will produce another prompt to accept another line of expression input. This is primarily to make it easier to paste in multi-line expressions taken from elsewhere, but it could also be used for manual input. The support for multi-line _editing_ is limited by the fact that the readline dependency we use doesn't support multiline input and so we're currently doing this in spite of that library. Hopefully we'll be able to improve on that in future either by contributing multi-line editing support upstream or by switching to a different readline dependency. The delimiter-counting heuristic employed here is similar to the one used by HCL itself to decide whether a newline should end the definition of an attribute, but this implementation is simpler because it doesn't need to produce error messages or perform any recovery. Instead, it just bails out if it encounters something strange so that the console session can return a parse error. Because some invalid input may cause a user to become "stuck" in a multi- line sequence, we consider a blank line as intent to immediately try to evaluate what was entered, and also interpret SIGINT (e.g. Ctrl+C) as cancellation of multi-line input, assuming that at least one line was already entered, extending the previous precedent that SIGINT cancels when at least one character was already entered at the prompt.	2 years ago
Liam Cervante	c6ff573180	Include provider functions in scope used to evaluate test assertions (#34825)	2 years ago
Martin Atkins	88cb4aeea3	backendrun: Separate the types/etc for backends that support operations ... We previously had all of the types and helpers for all kinds of backends together in package backend. That kept things relatively simple, but it also meant that the majority of backends that only deal with remote state storage ended up still indirectly depending on the entire Terraform modules runtime, configuration loader, etc, etc, which brings into scope a bunch of external dependencies that the remote state backends don't really need. Since backends that support operations are a rare exception, we'll move the types and helpers for those into a separate package "backendrun", and then the main package backend can have a much more modest set of types and, more importantly, a modest set of dependencies on other packages in this codebase. This is part of an ongoing effort to reduce the exposure of Terraform Core and CLI code to the remote backends and vice-versa, so that in the long run we can more often treat them as separate for dependency maintenance purposes.	2 years ago
Martin Atkins	545980d664	langrefs: Separate package for expression reference analysis ... Finding references in an expression is a static analysis operation, but we previously had it grouped in with "package lang" that primarily deals with dynamic evaluation of expressions. We need to do static analysis in far more locations than we do full expression evaluation, the static-analysis-only callers don't need anything else from package lang, and the reference-analysis functions are self-contained little wrappers around the address parsing logic in package addrs anyway. Splitting these into a separate package therefore minimizes which packages depend indirectly on package lang, and thus which packages depend indirectly on the implementations of the built-in functions. Some of the built-in functions rely on dependencies we don't use anywhere else, so cutting these out shrinks how many packages indirectly depend on those external dependencies. In particular, they are no longer in the indirect import chain for the "legacy" module.	2 years ago
Martin Atkins	5f2eab6944	providerreqs: Provider requirement/version types in their own package ... As we previously found with "package addrs", any package that contains types used as identifiers or addresses tends to get imported from all over, which means that if we mix real logic with those types in the same package then a lot more packages end up depending indirectly on our external dependencies. In this case, the getproviders package depends on various things we need only during provider installation, such as the library we use for GPG signature verification. Lots of different packages in Terraform need to talk about provider requirements, but only the CLI layer actually needs to do provider installation, and so this commit splits the types we use to talk about requirements into a new package "providerreqs", which package getproviders then depends on. To keep the size of this diff relatively small to start I've left forwarding aliases in package getproviders, which means that not all of the callers needed to be updated all at once. This commit does update all of the packages that the remote state backends depend on though, because that then allows us to reduce the set of indirect dependencies for each of those backends. The nested module go.mod files show that this has disconnected the indirect dependencies on github.com/ProtonMail/go-crypto and on github.com/cloudflare/circl , both of which Terraform CLI uses only for provider installation.	2 years ago
Martin Atkins	66bec6c3c7	command: TestWorkspace_deleteWithState uses modern state format ... This test is intending to test behavior in the presence of a state snapshot but was achieving that using the legacy state snapshot format that we preserved only for its previous (now eliminated, in an earlier commit) purpose of implementing the CLI backend state format. Instead, we'll construct a state snapshot format using the modern API for doing that, which therefore constructs a modern state snapshot file as would be created by today's Terraform. This eliminates the last use of the "legacy/terraform" package aside from the calls from other packages under "legacy".	2 years ago
Martin Atkins	06f51dbe04	command/workdir: Model the "backend state" file format ... Historically (before there were "backends") Terraform had a single state file format used both for real state snapshots and for tracking where remote state was stored. Terraform v0.12 caused these two to be split because we adopted state snapshot version 4 for real snapshots but retained a subset of version 3 for tracking the remote backend configuration in the local working directory. Unfortunately we previously kept that working by retaining a snapshot of the entire Terraform v0.11 "terraform" package as legacy/terraform, which happened to still be around because we also needed to retain a copy of the entire legacy SDK to keep the remote state backends working. This now hoists just the tiny slice of legacy terraform package functionality needed to implement the "backend state" file format into package workdir. This package is a good home for it because it's part of the working directory state. Ideally it would be accessed through methods of the workdir.Dir type, but that's too disruptive a refactor to combine into this and so that'll need to wait for another day; for now we'll keep the existing callers doing their access through our "clistate" package that is itself a forked snapshot of what statemgr.Filesystem used to be in Terraform v0.11. This removes all but one of the uses of "legacy/terraform" aside from calls in the other packages under "legacy". We'll clean up the last one in a later commit, because it's not related to the backend state file format.	2 years ago
Martin Atkins	1358245617	dependencies: Remove all non-legacy uses of hashicorp/go-multierror ... This functionality is now provided by the "errors" package in the standard library, so the HashiCorp-specific library is obsolete. This also removed our one direct use of github.com/pkg/errors, which we were using in a way that was totally redundant with the stdlib package errors. However, it lives on as an indirect dependency through the Consul backend's dependency on the Consul SDK, which uses that library.	2 years ago
thirdkeyword	8284cde302	remove repetitive words ... Signed-off-by: thirdkeyword <fliterdashen@gmail.com>	2 years ago
Mark DeCrane	57d2802053	Merge pull request #34746 from hashicorp/modify-dev-override-warn-with-backend ... Modify provider dev override warning to include a remote backend specific line	2 years ago
Mark DeCrane	b83275f05d	chore: remove extra newline char	2 years ago
Mark DeCrane	51ae7d32a7	fix: check for local operations, separate warning for remote execution	2 years ago
Mark DeCrane	9580ee27f9	chore: add remote backend specfic warnings to dev override warning	2 years ago
Nick Fagerlund	c9c24706aa	Merge pull request #34741 from hashicorp/nf/feb24-provider-addrs-in-statuses ... Stacks, Hooks: Include full provider addresses	2 years ago
James Bardin	dada9d683e	Merge pull request #34740 from hashicorp/jbardin/render-string-null-changes ... try to render some changes between `""` and `null`	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
Martin Atkins	573c2db658	provider/terraform: Terraform-specific encoding functions ... Using the new possibility of provider-contributed functions, this introduces three new functions which live in the terraform.io/builtin/terraform provider, rather than being language builtins, due to their Terraform-domain-specific nature. The three new functions are: - tfvarsencode: takes a mapping value and tries to transform it into Terraform CLI's "tfvars" syntax, which is a small subset of HCL that only supports key/value pairs with constant values. - tfvarsdecode: takes a string containing content that could potentially appear in a "tfvars" file and returns an object representing the raw variable values defined inside. - exprencode: takes an arbitrary Terraform value and produces a string that would yield a similar value if parsed as a Terraform expression. All three of these are very specialized, of use only in unusual situations where someone is "gluing together" different Terraform configurations etc when the usual strategies such as data sources are not suitable. There's more information on the motivations for (and limitations of) each function in the included documentation.	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
Daniel Schmidt	8564e934aa	Merge pull request #34699 from hashicorp/terraform-test-use-vars-within-blocks ... test: allow using global variables in suite-level variable definitions	2 years ago
Daniel Schmidt	0529299cc3	run terraform fmt on test	2 years ago
Liam Cervante	c46515c5da	stacks: add support for external providers to validate context (#34701)	2 years ago
Daniel Schmidt	7ae7a203d8	test: allow using global variables in suite-level variable definitions ... Closes #34534	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
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
Daniel Schmidt	91ea23aee5	remove outdated comment	2 years ago
Daniel Schmidt	14feb738a7	update comment	2 years ago
Daniel Schmidt	472a07ad6e	fix typo ... Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com>	2 years ago
Daniel Schmidt	be262b52d7	make using the plugin cache opt-in	2 years ago
Daniel Schmidt	f720a060ff	use plugin cache for provider lock across for all platforms ... The cache architecture already supports multi-platform, the only downside is that this might grow the cache. This seems expected.	2 years ago
Daniel Schmidt	2c98e6a347	improve provider lock speed by using cache ... Closes #33837	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
HenriBlacksmith	49663bfc33	terraform fmt: add .tfmock.hcl as a supported file extension (#34580) ... * terraform fmt: add .tfmock.hcl as a supported file extension * terraform fmt: add test cases for .tfmock.hcl files formatting * fix: update test to run on .tfmock.hcl files	2 years ago
James Bardin	c4a2f74054	Merge pull request #34567 from hashicorp/jbardin/handling-instance-value-marks ... apply schema marks to returned instance values	2 years ago
James Bardin	8994e914b7	add sensitive attributes to test json output	2 years ago
James Bardin	8655b08b19	fix sensitive_attributes in test ... Add the missing sensitive_attributes to the test state, and update the output to reflect the new `"checks"` attribute name.	2 years ago
Liam Cervante	9658f9df6b	mocking overrides: default to concrete empty object when values are missing (#34563)	2 years ago
Liam Cervante	430970c02b	terraform test: Fix crash when file level variables reference variables. (#34531) ... * terraform test: Fix crash when referencing variables within the file level variable block * also allow functions within variables blocks * add tests	2 years ago
Brian Flad	3b4964270f	internal/command/jsonprovider: Remove root jsonfunction object from function output (#34536) ... Previously, the `providers schema -json` output would include the root object from `metadata functions -json`. This object had its own `format_version` property, which would be confusing with the root `format_version` property already present. This change still uses the `jsonfunction` package for consistency between cty and provider function JSON handling, but removes that extra object, instead making `functions` directly a mapping of names to signatures/definitions. This also adds a code comment to hint maintainers that jsonprovider format versioning is tied to jsonfunction format versioning. Example output prior to change: ```jsonc { "format_version": "1.0", "provider_schemas": { "registry.terraform.io/bflad/framework": { // ... "functions": { "format_version": "1.0", "function_signatures": { "example": { "description": "Echoes given argument as result", "summary": "Example function", "return_type": "string", "parameters": [ { "name": "input", "description": "String to echo", "type": "string" } ] } } } } } } ``` Example output after change: ```jsonc { "format_version": "1.0", "provider_schemas": { "registry.terraform.io/bflad/framework": { // ... "functions": { "example": { "description": "Echoes given argument as result", "summary": "Example function", "return_type": "string", "parameters": [ { "name": "input", "description": "String to echo", "type": "string" } ] } } } } } ```	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
Brian Flad	1298fcd412	Add missing function deprecation_message to JSON output and website documentation (#34520) ... Reference: https://github.com/hashicorp/terraform/pull/34450	2 years ago
James Bardin	b3c5590f01	Merge pull request #34450 from hashicorp/jbardin/provider-functions-json-schema ... Add functions definitions to the `providers schema -json` output	2 years ago
James Bardin	2e74fec583	add optional Summary field to function json	2 years ago
Nick Fagerlund	9d7737b2fe	Merge pull request #34447 from hashicorp/nf/dec23-grpc-metadata-cloudplugin ... Cloudplugin: Pass configuration via gRPC metadata	2 years ago
Nick Fagerlund	ff62192819	Adjust CloudPluginConfig doc comments	2 years ago
Liam Cervante	7e18b1183d	Add test verifying issue #34476 has been fixed (#34478)	2 years ago
Nick Fagerlund	1a492b9dbb	Add test for (CloudPluginConfig).ToMetadata()	2 years ago
Nick Fagerlund	c398d0340f	Catch a missing assign-after-append ... I believe this is a slice append under the hood, which would mean `.Append()` consumes the original receiver and you shouldn't touch it afterwards.	2 years ago
Nick Fagerlund	7a1c49c61d	Append cloud plugin config metadata in plugin client requests ... - The cloud plugin wants a go-tfe client to get stuff from TFC. - Terraform knows how to find all the info you need in order to configure a go-tfe client, but it's sometimes scattered across configs and env vars and credentials helpers, and trying to re-implement the resolution logic identically in another codebase would be error-prone. - Therefore, it'd be best if Terraform did that resolution and just passed the plugin all the config info it needs. There are two options for that handoff: 1. Adding it as an additional argument to the primary Execute RPC interface. 2. Passing it as gRPC metadata, which is a pile of arbitrary key => list-of-strings pairs transmitted via HTTP/2 headers. The crux of the decision here is whether a proliferation of plugin protocol versions whenever we need to add more config data is better or worse than a fuzzy and typeless key/value bag. This PR is an implementation of option 2, for discussion and evaluation. (And after all, this is considered an experimental feature anyway.) It assembles the necessary information, translates it to the required metadata format, and attaches it to the request at the proper moment to get everything over to the plugin. As previous commits foreshadowed, we're leaning on the existing logic in the Cloud backend for pretty much all of this.	2 years ago
Nick Fagerlund	e1f0165693	Cloud command: Use cloud backend to find plugin config and service URLs ... The plugin needs some config info in order to actually build a go-tfe client and _do_ anything, and the Cloud backend is the one place that already knows how to look up and reconcile all the possible sources of that info. So, we'll just find a Cloud backend and pick its pockets. This also replaces our reimplementations of hostname lookup and service discovery, using work the Cloud backend already did.	2 years ago
James Bardin	6553e55dfa	marshal provider functions into the json schemas ... Add provider functions to the json schema output for providers. We leverage the jsonfunction package here to ensure that the serialization is kept identical, so that the consumers of the json function definitions can work equally with both.	2 years ago
James Bardin	a74c847656	test MarshalProviderFunctions ... Provider functions should marshal identically to an equivalent cty functions.	2 years ago
James Bardin	8c41a1e036	MarshalProviderFunctions	2 years ago
James Bardin	d7a1ebb1b7	add special cases for jsonfunction ... The jsonfunction package has special cases for some internal functions, and wee need to add the namespaced equivalents to those lists.	2 years ago
Jamie Finnigan	05b0bdac99	adopt hashicorp/cli fork of mitchellh/cli (#34429)	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
James Bardin	a9cc3baf1a	ensure unmanaged plugins have an address ... Unmanaged plugins use a slightly different factory function which was missed when adding the address to the plugin struct. This made little difference in most cases, but now with the new global schema cache it would prevent the plugin's schema from being cached due to lack of a key. The end result was acceptance tests for very large providers would take considerably longer due to the overhead of repeatedly generating the schema. There is no good way to check the internals of an unmanaged provider in a unit test, but this PR puts the setup functionality in a single helper function so that unmanaged providers use the same setup codepath as the standard set of plugins.	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
Liam Cervante	5cbf7c5f96	Add docs for automatic var files in test directories (#34349)	2 years ago
Nick Fagerlund	d2e07f6f03	Add `TF_CLOUD_PLUGIN_DEV_OVERRIDE` to enable cloudplugin dev ... Currently, Terraform will only run properly signed versions of the experimental cloud plugin that were downloaded from a TFC instance that provides the appropriate service. That obstructs development on new cloud plugin features! Our internal teams will need a "dev override" capability, like what we offer provider authors. However, unlike with providers, we don't have to integrate this into a heterogeneous mix of sources for mirroring and caching a wide range of binaries. There's only one cloud plugin, HashiCorp controls it, and end users should never need to override the location of the binary for non-development reasons. Thus, we have the luxury of being quite a bit stupider in how we handle the override signal. Instead of adding it to the CLI config file schema, we'll just use a single environment variable whose value is the path to an alternate binary. Enter: `TF_CLOUD_PLUGIN_DEV_OVERRIDE`.	2 years ago
Nick Fagerlund	9a7fae5ff1	Typo fix	2 years ago
Kubo	c98e355ca1	terraform test: Collect variables from default var file within testing directory (#34341) ... * Add logic to collect variables for terrafrom test * Add tests for test variable collection * Update the test variable collection implementation * Update internal/backend/local/test.go Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com> * Update internal/backend/local/test.go Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com> * Move test variables into var file * resolve diff from cross-branch switch * go fmt --------- Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com>	2 years ago
Martin Atkins	7055650270	terraform console: Option to evaluate in a planned state ... Previously "terraform console" always evaluated in a kinda strange context where resource instance data comes from the prior state, but other derived of values end up being calculated dynamically based on the current configuration, which is okay for simple cases but can be confusing if the configuration has changed significantly since the most recent apply, or if there haven't yet been any applied changes. Now we'll allow an optional new mode where Terraform runs the normal plan phase (as if running "terraform plan") and then uses the resulting _planned state_ as the basis for evaluation, allowing evaluation against a partial approximation of what the world ought to look like if these changes were applied, without having to actually apply them first. As with the previous use of the eval walk, it's possible that an erroneous situation will still produce a partial evaluation scope, and so the console still allows evaluation against that scope but with a caveat that it might produce unexpected results. In practice this can be useful for debugging situations like when unknown values block planning of an object, to allow inspection of the values that are contributing to that blocked planning operation even though the plan is not yet complete.	2 years ago
Martin Atkins	0f845adfdb	moduletest: EvalContext lives outside of the "terraform" package ... The initial implementation of the module testing language included some elements deeply embedded inside "package terraform", which is primarily concerned with the traditional Terraform language, which we might now call the "module language" to distinguish it from the test language and the stacks language. That was a reasonable design decision due to the modules runtime needing to evaluate some expressions in a similar way to how the modules language does it, but unfortunately it caused the test language runtime to depend a little too closely on some current implementation details of how the modules runtime deals with expression evaluation, and those details are about to change as we teach Terraform to be able to deal with unknown values in new places, as part of resolving this issue: https://github.com/hashicorp/terraform/issues/30937 This commit therefore refactors the test runtime a little so that it doesn't intrude so deeply into the module runtime's business. Instead of directly extending the module runtime's expression evaluator, we'll instead call into it in a similar way to how the "terraform console" command does, by wrapping the evaluation data produced by the module runtime to extend it with the only two special things that the test runtime needs: references to the output values of previous runs, and references to test-only variables that aren't declared as part of the module under test. This effectively means that the test runtime can now evaluate a superset of the expressions that would be valid in the global scope of the module under test using only the public API of the modules runtime, with no testing-specific evaluation logic embedded inside the modules runtime. This new strategy is also somewhat similar to how the stacks runtime calls into the modules runtime to evaluate components, but the stacks runtime only actually cares about output values and so doesn't need a full evaluation scope. This means the result here is a little more symmetrical with the approach we took in stacks, which will hopefully allow experience working on one to translate better to the other.	2 years ago
Liam Cervante	9ea1aa0a86	terraform test: skip destroy step for empty run blocks (#34331)	2 years ago
Liam Cervante	392e2a6e21	Fix the compile error in command/test_test.go (#34324)	2 years ago
Liam Cervante	6670ab43f7	terraform test: rearrange the order of destroy operations (#34293)	2 years ago
Liam Cervante	08eafe0f2e	Fix flaky test in command/test_test.go (#34320)	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	844b1616e8	command/graph: Simpler resource-only graph by default ... Unless a user specifically requests a real operation graph using the -type option, we'll by default present a simplified graph which only represents the relationships between resources, since resources are the main side-effects and so the ordering of these is more interesting than the ordering of Terraform's internal implementation details.	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	dedb296773	terraform test: connect mock behaviour to test framework (#34205) ... * connect mock behaviour to test framework * fix calling unconfigured providers	2 years ago
Liam Cervante	57edb9c248	testing framework: add warnings for override blocks with invalid targets (#34181) ... * testing framework: add warnings for override blocks with invalid targets * pre-add the override sources for upcoming features * address comments	2 years ago