1523 Commits (49f99db1c28a463ff818dfa94730ce3a6f00a0a9)

Author	SHA1	Message	Date
Andrew Hickman	49f99db1c2	`terraform show -json`: Add Errored field to output for plan (#33372) ... * Add Errored field to JSON output * Fix test error message	3 years ago
James Bardin	f6c536e436	validate planned set sizes using refinements	3 years ago
James Bardin	3c8a163583	set length is unknown with partially known elems ... If a set contains partially known values the length is unknown which causes assertPlannedObjectValid to fail valid plans. Revert to the old method if using LengthInt for the set lengths, which returns the maximum number of possible elements, with a guard for entirely unknown set values.	3 years ago
Liam Cervante	ce8fd2943d	[Testing Framework] Add test structure to views package for rendering test output (#33324) ... * Add test structure to views package for rendering test output * address comments	3 years ago
guimin.hgm	ce8790c939	backend/oss: Removes the deprecated warning for configuraion variable assume_role	3 years ago
Liam Cervante	48c818927c	Remove old implementation of terraform test command	3 years ago
Katy Moe	7ce5503c7a	views: fix wordwrap	3 years ago
Liam Cervante	361d43c820	Ensure nested data blocks execute last of all Terraform resources (#33301) ... * Ensure nested data blocks execute last of all Terraform resources * add test, execute only during apply * address comments	3 years ago
kmoe	5900d1177c	cloud: assert import block compatibility (#33282) ... * cloud: assert import block compatibility * check for import <> TFC compatibility during init * imports are not in alphabetical order 🙃 --------- Co-authored-by: CJ Horton <cjhorton@hashicorp.com>	3 years ago
kmoe	4386a15684	command: help text for generate-config-out (#33279)	3 years ago
kmoe	1e31c671c2	terraform: expanded resources cannot genconfig (#33293) ... This temporary measure prevents a panic further down the line when there is an unmatched expanded resource instance import target when running in config gen mode.	3 years ago
CJ Horton	8213513e2b	Merge pull request #33278 from hashicorp/radditude/cloud-config-generation ... plannable import: allow writing generated config when using the cloud integration	3 years ago
CJ Horton	8a3f4e903b	generating configuration is not allowed with the remote backend	3 years ago
CJ Horton	6ca13bfc1e	fix static check errors	3 years ago
Brandon Croft	ea0ebcdc05	Merge pull request #33267 from hashicorp/sebasslash/snapshot-interval-header-check ... [cloud] Add interval header check to enable snapshots	3 years ago
Brandon Croft	86eed095b3	Rename disableIntermediateSnapshots > enableIntermediateSnapshots	3 years ago
Martin Atkins	9f6a3ba701	build: Generate copyright headers automatically ... HashiCorp legal now requires a copyright claim in a comment at the top of every substantial file in this repository. If we don't add this ourselves then a bot will open a PR to add missing entries, but that process adds git history, pull request, and GitHub notification noise so instead we'll deal with it proactively as part of our usual code generation steps. This means that pull requests will fail their checks if there are any files that lack copyright headers, so we can deal with those before we merge rather than in a subsequent PR.	3 years ago
CJ Horton	cdce4c4a6d	write generated config when using the cloud integration	3 years ago
CJ Horton	b88bae2ec4	tests for cloud backend config generation	3 years ago
Sebastian Rivera	d03fd37ee6	Add interval header check to enable snapshots	3 years ago
Martin Atkins	4c439b099f	plans/objchange: Don't consider refinements when validating plans ... Providers that existed prior to refinements (all of them, at the time of writing) cannot preserve refinements sent in unknown values in the configuration, and even if one day providers _are_ aware of refinements there we might add new ones that existing providers don't know how to handle. For that reason we'll absolve providers of the responsibility of preserving refinements from config into plan by fixing some cases where we were incorrectly using RawEquals to compare values; that function isn't appropriate for comparing values that might be unknown. However, to avoid a disruptive change right now this initial fix just strips off the refinements before comparing. Ideally this should be using Value.Equals and handling unknown values more explicitly, but we'll save that for a possible later improvement. This does not include a similar exception for validating whether a final value conforms to a plan because the plan value and the final value are both produced by the same provider and so providers ought to be able to be consistent with their _own_ treatment of refinements, if any. Configuration is special because Terraform itself generates that, and so it can potentially contain refinements that a particular provider has no awareness of.	3 years ago
Martin Atkins	dfe5e1ddc4	plans/objchange: Providers must honor their unknown value refinements ... If the original value was unknown but its range was refined then the provider must return a value that is within the refined range, because otherwise downstream planning decisions could be invalidated. This relies on cty's definition of whether a value is in a refined range, which has pretty good coverage for the "false" case and so should give a pretty good signal, but it'll probably improve over time and so providers must not rely on any loopholes in the current implementation and must keep their promises even if Terraform can't currently check them.	3 years ago
Martin Atkins	81c15f987e	lang/funcs: startswith considers string prefix refinement ... If the string to be tested is an unknown value that's been refined with a prefix and the prefix we're being asked to test is in turn a prefix of that known prefix then we can return a known answer despite the inputs not being fully known. There are also some other similar deductions we can make about other combinations of inputs. This extra analysis could be useful in a custom condition check that requires a string with a particular prefix, since it can allow the condition to fail even on partially-unknown input, thereby giving earlier feedback about a problem.	3 years ago
Martin Atkins	691018dd00	builtin/providers/terraform: terraform_data "id" is guaranteed non-null ... The "id" attribute of this resource type is generated by the provider itself and can never be null, so we'll refine the range of its unknown result in case that helps downstream expressions to produce known results even when the exact value hasn't yet been planned.	3 years ago
Martin Atkins	696cd68913	command/views: Describe unknown collection bounds in diagnostics	3 years ago
Martin Atkins	c912970153	lang/funcs: Non-null refinements for various functions ... cty's new "refinements" concept allows us to reduce the range of unknown values from our functions. This initial changeset focuses only on declaring which functions are guaranteed to return a non-null result, which is a helpful baseline refinement because it allows "== null" and "!= null" tests to produce known results even when the given value is otherwise unknown. This commit also includes some updates to test results that are now refined based on cty's own built-in refinement behaviors, just as a result of us having updated cty in the previous commit.	3 years ago
Liam Cervante	07aa7ee1d5	Propagate generated config filename into the Terraform graph (#33255)	3 years ago
James Bardin	2106b4c05f	Merge pull request #33235 from hashicorp/jbardin/destroy-root-referenced-locals ... Remove destroy-plan locals only referenced by root outputs	3 years ago
kmoe	be2ad69eda	plannable import: safer config generation and schema filters (#33232) ... * genconfig: fix nil nested block panic * genconfig: null NestingSingle blocks should be absent A NestingSingle block that is null in state should be completely absent from config. * configschema: make FilterOr variadic * configschema: apply filters to nested types * configschema: filter helper/schema id attribute The legacy SDK adds an Optional+Computed "id" attribute to the resource schema even if not defined in provider code. During validation, however, the presence of an extraneous "id" attribute in config will cause an error. Remove this attribute so we do not generate an "id" attribute where there is a risk that it is not in the real resource schema. * configschema: filter test * terraform: do not pre-validate generated config Config generated from a resource's import state may fail validation in the case of schema behaviours such as ExactlyOneOf and ConflictsWith. We don't want to fail the plan now, because that would give the user no way to proceed and fix the config to make it valid. We allow the plan to complete and output the generated config. * generate config alongside import process Rather than waiting until we call `plan()`, generate the configuration at the point of the import call, so we have the necessary data to return in case planning fails later. The `plan` and `state` predeclared variables in the plan() method were obfuscating the actual return of nil throughout, so those identifiers were removed for clarity. * move generateHCLStringAttributes closer to caller * store generated config in plan on error * test for config gen with error * add simple warning when generating config --------- Co-authored-by: James Bardin <j.bardin@gmail.com>	3 years ago
Martin Atkins	f6737d47e7	cloud: Allow Cloud API to lower the intermediate state snapshot interval ... Previously we just made a hard rule that the state storage for Terraform Cloud would never save any intermediate snapshots at all, as a coarse way to mitigate concerns over heightened Terraform Enterprise storage caused by saving intermediate snapshots. As a better compromise, we'll now create intermediate snapshots at the default interval unless the Terraform Cloud API responds with a special extra header field X-Terraform-Snapshot-Interval, which specifies a different number of seconds (up to 1 hour) to wait before saving the next snapshot. This will then allow Terraform Cloud and Enterprise to provide some dynamic backpressure when needed, either to reduce the disk usage in Terraform Enterprise or in situations where Terraform Cloud is under unusual load and needs to calm the periodic intermediate snapshot writes from clients. This respects the "force persist" mode so that if Terraform CLI is interrupted with SIGINT then it'll still be able to urgently persist a snapshot of whatever state it currently has, in anticipation of probably being terminated with a more aggressive signal very soon.	3 years ago
Martin Atkins	efdc6e52bc	cloud: Skip intermediate state snapshots in Terraform Cloud/Enterprise ... We've seen some concern about the additional storage usage implied by creating intermediate state snapshots for particularly long apply phases that can arise when managing a large number of resource instances together in a single workspace. This is an initial coarse approach to solving that concern, just restoring the original behavior when running inside Terraform Cloud or Enterprise for now and not creating snapshots at all. This is here as a solution of last resort in case we cannot find a better compromise before the v1.5.0 final release. Hopefully a future commit will implement a more subtle take on this which still gets some of the benefits when running in a Terraform Enterprise environment but in a way that will hopefully be less concerning for Terraform Enterprise administrators. This does not affect any other state storage implementation except the Terraform Cloud integration and the "remote" backend's state storage when running inside a TFC/TFE-driven remote execution environment.	3 years ago
Martin Atkins	8884bef59d	backend/local: Allow storage impls to customize intermediate persistence ... Previously we just always used the same intermediate state persistence behavior for all state storages. However, some storages might have access to additional information that allows them to tailor when they persist, such as reacting to API rate limit status headers in responses, or just knowing that a particular storage isn't suited to intermediate snapshots at all for some reason. This commit doesn't actually change any observable behavior yet, but it introduces an optional means for a state storage to customize the behavior which we may make use of in certain storage implementations in future commits.	3 years ago
CJ Horton	258bdbe89f	Merge pull request #33238 from hashicorp/radditude/import-plan-plumbing ... plannable import: correct plumbing when using a plan output file	3 years ago
James Bardin	2f308cf948	Merge pull request #32962 from hashicorp/jbardin/validate-unknown-coll-attrs ... validate unknown nested attribute collections	3 years ago
CJ Horton	40ff381887	plumb import changes to and from binary plan	3 years ago
James Bardin	0a921976cd	destroy locals referenced by root outputs ... When planning a destroy operations, locals only referenced by root outputs do not need to be kept in the graph, because the root output does not get evaluated. Rather than try and prune the local based on this condition, we can prevent the connection from being created by ensuring that a root output destroy node has no references. The separate plan+apply destroy fields used for outputs can be simplified by combining, since they are only ever referenced together.	3 years ago
Masayuki Morita	53755180fd	Fix an error message for import block with moved block (#33221) ... Fixes #33220	3 years ago
kmoe	4015f1aa30	genconfig: do not generate null NestingSingle blocks (#33213) ... * genconfig: fix nil nested block panic * always InternalValidate test schemas * genconfig: null NestingSingle blocks should be absent A NestingSingle block that is null in state should be completely absent from config.	3 years ago
kmoe	b4d1146f58	plannable import: improve gen config human plan output (#33194) ... * renderer: remove hard-coded config gen path * mention config gen file in plan next steps	3 years ago
kmoe	789e30dfc5	error if importing to invalid keyed address (#33191) ... Import addresses targeting expanded resource instances must target instances that already exist in configuration.	3 years ago
CJ Horton	adcecddb4f	Merge pull request #33193 from hashicorp/radditude/no-import-blocks-in-child-modules ... plannable import: disallow import blocks in child modules	3 years ago
kmoe	1172d40d7b	error if import target is move source (#33192) ... It is invalid for any import block to have a "to" argument matching any moved block's "from" argument.	3 years ago
CJ Horton	2dd89d9776	import blocks are only allowed in the root module	3 years ago
CJ Horton	bd6ba6cf99	check for duplicate import blocks (#33190) ... Importing to the same target address twice or importing the same ID to multiple different resources of the same type is not allowed.	3 years ago
Liam Cervante	d5fed58fc5	plannable import: write generated config to out flag (#33186) ... * plannable import: write generated config to out flag * Add example command to diagnostic	3 years ago
kmoe	2b71e9edf3	terraform: config-driven import is idempotent (#33188) ... If a resource is already in state, do not attempt to import it again. Resources already in state are filtered out of the plan's import targets. A change is only considered "importing" if it is adding a new resource instance to the state.	3 years ago
CJ Horton	5d7864316e	Merge pull request #33160 from hashicorp/radditude/apply-counts ... Populate import counts during applies and clean up output	3 years ago
CJ Horton	e5a6806206	clarify apply hook usage	3 years ago
Liam Cervante	cd06543b39	plannable import: fix config generation printing empty collections instead of null values (#33183)	3 years ago
Liam Cervante	192cb255a6	checks: no longer experimental (#33184)	3 years ago