665 Commits (7e767490c87bae2fa2b60da33ecefa1b7a220afa)

Author	SHA1	Message	Date
James Bardin	2cbb6bf92f	udpate code which was failing staticckeck ... Some updates to staticcheck were catching more errors. Most of these were format functions without a format string, but rather than adding more exceptions I just fixed them all. This did also catch some incorrectly wrapped errors.	2 years ago
Liam Cervante	332757894d	plan renderer: fix crash when updating a null attribute to unknown (#35709)	2 years ago
Liam Cervante	abd6b9ef1b	plan renderer: render unknown nested blocks properly (#35644)	2 years ago
kmoe	a2039517a5	states: store ephemeral output values in memory (#35676) ... Ephemeral root output values must be kept in the in-memory state representation, but not written to the state file. To achieve this, we store ephemeral root outputs separately from non-ephemeral root outputs, so Terraform can access them during a single plan or apply phase. Ephemeral root outputs always have a value of null in the state file. This means that the "terraform output" command, that reads the state file, reports null values for these outputs. Consumers of 'terraform output -json' should use the presence of '"ephemeral": true' in such output to interpret the value correctly.	2 years ago
makx	2a9a8c2aca	show deprecation warning if -state is used with plan, apply, refresh (#35660) ... * show deprecation warning if -state is used with plan, apply, refresh * show deprecation warning if -state is used with plan, apply, refresh * updated -state flag check condition * added better diagnostic details view * resolved failed test * updated the content of the -state flag warning	2 years ago
Radek Simko	91ea2cd6e0	internal/command: Avoid ignoring ephemeralasnull function (#35651)	2 years ago
kmoe	fab3673f8d	lang: stabilise ephemeral values experiment (#35636) ... * lang: stabilise ephemeral values experiment Stabilise the ephemeral values experiment and ephemeralasnull experimental function. * simplify handling of apply time input vars As the final step in stabilising the ephemeral values experiment, we can remove the separate code path for handling input variables supplied via -var and -var-file during apply. The intent here is conveyed in the tests: when applying a saved plan, all ephemeral variables set in the plan (the "apply-time variables"), must be set, and no others. As per the TODO copied from the prototype, there is some more work to be done here in making the handling of undeclared variables during apply as sophisticated as that during plan, emitting helpful warnings (for example) when input variables are supplied unnecessarily via environment variables. * experiments: officially conclude EV experiment --------- Co-authored-by: Radek Simko <radek.simko@gmail.com>	2 years ago
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