573 Commits (8564e934aa57cc59459581ee06479879ebf41bf0)

Author	SHA1	Message	Date
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