1131 Commits (ba113ff2cd3708d8a0e49df66d649774af5aaa4e)

Author	SHA1	Message	Date
kmoe	ba113ff2cd	add destroy option to terraform apply help text (#31714)	4 years ago
James Bardin	522556534d	remove deprecated backends (#31711) ... * remove deprecated backends * remove backend docs Remove references to deprecated backends from docs.	4 years ago
megan07	cb340207d8	Merge pull request #31698 from hashicorp/megan_tf563 ... Send the JSON state representation to Cloud backend (when available)	4 years ago
Megan Bang	37b7e6ebce	don't check diags for errors	4 years ago
Megan Bang	4d749e2813	add warning to diags and show at the end of each command	4 years ago
Megan Bang	5eaa4c45c0	fix imports	4 years ago
Megan Bang	de8bd5826f	first part of code review comments	4 years ago
kmoe	dec48a8510	plans: indicate when resource deleted due to move (#31695) ... Add a new ChangeReason, ReasonDeleteBecauseNoMoveTarget, to provide better information in cases where a planned deletion is due to moving a resource to a target not in configuration. Consider a case in which a resource instance exists in state at address A, and the user adds a moved block to move A to address B. Whether by the user's intention or not, address B does not exist in configuration. Terraform combines the move from A to B, and the lack of configuration for B, into a single delete action for the (previously nonexistent) entity B. Prior to this commit, the Terraform plan will report that resource B will be destroyed because it does not exist in configuration, without explicitly connecting this to the move. This commit provides the user an additional clue as to what has happened, in a case in which Terraform has elided a user's action and inaction into one potentially destructive change.	4 years ago
Megan Bang	7e5b7b283e	updates for code consistency	4 years ago
Megan Bang	dbf99f17b1	add test and removed backend state from cloud	4 years ago
Megan Bang	b504dd1489	update from code consistency checks	4 years ago
Megan Bang	485a1f6777	remove test for error	4 years ago
Megan Bang	bddf6a9b34	updating to use the latest version of cloud/state.go and just pass schemas along to PersistState in the remote state	4 years ago
Megan Bang	b572e57fb3	refactor GetSchemas to include an option to pass in a config	4 years ago
Megan Bang	40263cd861	undo taint test changes	4 years ago
Megan Bang	00cc1ea26d	refactor getSchemas	4 years ago
Martin Atkins	71dec301a2	command/jsonchecks: Mark check result objects as experimental ... This is a clumsy way to do this, but a pragmatic way to inform potential consumers that this part of the format is not yet finalized without having to read the docs to see our warning about that. We need to get some practical experience with a few different consumers making use of this format before we can be confident that it's designed appropriately. We're not _expecting_ to break it, but we'd like to leave the opportunity open in case we quickly learn that there's something non-ideal about this design.	4 years ago
Martin Atkins	a8c255c779	command/jsonstate: Include check results in JSON state report	4 years ago
Martin Atkins	0e4e9f7706	addrs: Be explicit about checkable object address kinds ... Previously we were attempting to infer the checkable object address kind of a given address by whether it included "output" in the position where a resource type name would otherwise go. That was already potentially risky because we've historically not prevented a resource type named "output", and it's also a forward-compatibility hazard in case we introduce additional object kinds with entirely-new addressing schemes in future. Given that, we'll instead always be explicit about what kind of address we're storing in a wire or file format, so that we can make sure to always use the intended parser when reading an address back into memory, or return an error if we encounter a kind we're not familiar with.	4 years ago
Martin Atkins	fe7e6f970e	command/jsonplan: Include new-style check results in JSON plan output ... This is a new-shaped representation of check results which follows the two-tiered structure of static objects and dynamic instances of objects, thereby allowing consumers to see which checkable objects exist in the configuration even if a dynamic evaluation error prevented actually expanding them all to determine their declared instances. Eventually we'll include this in the state too, but this initially adds it only to the plan in order to replace the now-deprecated experimental conditions result that was present but undocumented in Terraform v1.2.	4 years ago
Martin Atkins	d63871f70d	core: Propagate check results accurately from plan to apply ... In an earlier commit we changed the states.CheckResults model to explicitly model the config object vs. dynamic checkable object hierarchy, but neglected to update the logic in Terraform Core to take that into account when propagating the object expansion decisions from the plan phase to the apply phase. That meant that we were incorrectly classifying zero-instance resources always as having an unknown number of instances, rather than possibly being known to have zero instances. This now follows the two-level heirarchy of the data structure, which has the nice side-effect that we can remove some of the special-case methods from checks.State that we were using to bulk-load data: the data is now shaped in the appropriate way to reload the data using the same method the plan phase would've used to record the results in the first place.	4 years ago
Martin Atkins	6de3b1bd16	states/statefile: Serialize check results into state snapshots ... This allows us to retain check results from one run into the next, so that we can react to status changes between runs and potentially report e.g. that a previously-failing check has now been fixed, or that a previously-failing check is "still failing" so that an operator can get a hint as to whether a problem is something they've just introduced or if it was already an active problem before they made a change.	4 years ago
Martin Atkins	9e4861adbb	states: Two-level representation of check results ... A significant goal of the design changes around checks in earlier commits (with the introduction of package "checks") was to allow us to differentiate between a configuration object that we didn't expand at all due to an upstream error, which has _unknown_ check status, and a configuration object that expanded to zero dynamic objects, which therefore has a _passing_ check status. However, our initial lowering of checks.State into states.CheckResults stayed with the older model of just recording each leaf check in isolation, without any tracking of the containers. This commit therefore lightly reworks our representation of check results in the state and plan with two main goals: - The results are grouped by the static configuration object they came from, and we capture an aggregate status for each of those so that we can differentiate an unknown aggregate result from a passing aggregate result which has zero dynamic associated objects. - The granularity of results is whole checkable objects rather than individual checks, because checkable objects have durable addresses between runs, but individual checks for an object are more of a syntactic convenience to make it easier for module authors to declare many independent conditions that each have their own error messages. Since v1.2 exposed some details of our checks model into the JSON plan output there are some unanswered questions here about how we can shift to reporting in the two-level heirarchy described above. For now I've preserved structural compatibility but not semantic compatibility: any parser that was written against that format should still function but will now see fewer results. We'll revisit this in a later commit and consider other structures and what to do about our compatibility constraint on the v1.2 structure. Otherwise though, this is an internal-only change which preserves all of the existing main behaviors of conditions as before, and just gets us ready to build user-facing features in terms of this new structure.	4 years ago
Martin Atkins	3785619f93	core: Use the new checks package for condition tracking ... The "checks" package is an expansion what we previously called plans.Conditions to accommodate a new requirement that we be able to track which checks we're expecting to run even if we don't actually get around to running them, which will be helpful when we start using checks as part of our module testing story because test reporting tools appreciate there being a relatively consistent set of test cases from one run to the next. So far this should be essentially a no-op change from an external functionality standpoint, aside from some minor adjustments to how we report some of the error and warning cases from condition evaluation in light of the fact that the "checks" package can now track errors as a different outcome than a failure of a valid check. As is often the case with anything which changes what we track in the EvalContext and persist between plan and apply, Terraform Core is pretty brittle and so this had knock-on effects elsewhere too. Again, the goal is for these changes to not create any material externally-visible difference, and just to accommodate the new assumption that there will always be a "checks" object available for tracking during a graph walk.	4 years ago
Martin Atkins	9dea19807f	checks: A new package for modeling custom condition checks ... The checks.Checks type aims to encapsulate keeping track of check results during a run and then reporting on them afterwards even if the run was aborted early for some reason. The intended model here is that each new run starts with an entirely fresh checks.Checks, with all of the statuses therefore initially unknown, and gradually populates the check results as we walk the graph in Terraform Core. This means that even if we don't complete the run due to an error or due to targeting options we'll still report anything we didn't visit yet as unknown. This commit only includes the modeling of checks in the checks package. For now this is just dead code, and we'll wire it in to Terraform Core in subsequent commits.	4 years ago
Martin Atkins	696b403bf3	addrs: OutputValue.InModule ... Similar to other address types, this wraps the receiver up in its associated "config" type, binding it to a particular not-yet-expanded module.	4 years ago
Martin Atkins	209b8de7a5	configs: Variable and Output both have Addr methods ... We previously added methods like this for some of the other types in this package, including Local in this same file, but apparently haven't needed these two yet.	4 years ago
Martin Atkins	d06cbfe6c8	addrs: ConfigCheckable type ... Our existing addrs.Checkable represents a particular (possibly-dynamic) object that can have checks associated with it. This new addrs.ConfigCheckable represents static configuration objects that can potentially generate addrs.Checkable objects. The idea here is to allow us to predict from the configuration a set of potential checkable object containers and then dynamically associate the dynamic checkable objects with them as we make progress with planning. This is intended for our integration of checks into the "terraform test" testing harness, to be used instead of the weirdo builtin provider we were using as a placeholder before we had first-class syntax for checks. Test reporting tools find it helpful for there to be a consistent set of test cases from one run to the next so that they can report on trends over multiple runs, and so our ConfigCheckable addresses will serve as the relatively-static "test case" that we'll then associate the dynamic checks with, so that we can still talk about objects in the test result report even if we end up not reaching them due to an upstream conditution failure.	4 years ago
Megan Bang	344379f5c7	fix cloud state breaking?	4 years ago
Megan Bang	d5decc2407	update flow of schema checking	4 years ago
Megan Bang	12e3560d21	check for cloud integration mode	4 years ago
Megan Bang	021f1f69e9	updates to cloud state	4 years ago
Megan Bang	b8f2f81cd6	update to warn if schemas aren't available	4 years ago
Megan Bang	4fab46749a	update persist state	4 years ago
Martin Atkins	2ee9589650	lang/funcs: "timecmp" function ... This is a complement to "timestamp" and "timeadd" which allows establishing the ordering of two different timestamps while taking into account their timezone offsets, which isn't otherwise possible using the existing primitives in the Terraform language.	4 years ago
Martin Atkins	783a07d9e8	build: Use Go 1.19 ... Go 1.19's "fmt" has some awareness of the new doc comment formatting conventions and adjusts the presentation of the source comments to make it clearer how godoc would interpret them. Therefore this commit includes various updates made by "go fmt" to acheve that. In line with our usual convention that we make stylistic/grammar/spelling tweaks typically only when we're "in the area" changing something else anyway, I also took this opportunity to review most of the comments that this updated to see if there were any other opportunities to improve them.	4 years ago
Brandon Croft	76d40d281d	Merge pull request #31617 from glennsarti/gs/TF-410-add-prep-plan ... Add Pre-Plan Run Tasks to Terraform CLI	4 years ago
Glenn Sarti	8562f8a744	Add Pre-Plan Run Tasks to Terraform CLI ... Prevously the cloud backend would only render post-plan run tasks. Now that pre-plan tasks are in beta, this commit updates the plan phase to render pre-plan run tasks. This commit also moves some common code to the common backend as it will be used by other task stages in the future.	4 years ago
James Bardin	553b8c6de5	expand module subdir globs	4 years ago
Alisdair McDiarmid	4960e6aeba	Merge pull request #31634 from hashicorp/alisdair/optional-object-attribute-explicit-null ... typeexpr: Replace null attr values with defaults	4 years ago
kmoe	56a1e0d1c6	allow cross-package move statements (#31556)	4 years ago
Alisdair McDiarmid	27966044ba	Merge pull request #28191 from zimbatm/terraform-fmt-manyargs ... command/fmt: support formatting multiple files	4 years ago
Alisdair McDiarmid	c85ae29419	typeexpr: Replace null attr values with defaults ... Previously, when applying defaults to an input variable's given value before type conversion, we would permit `null` attribute values to override a specified default. This behaviour is inconsistent with the intent of the type system underlying Terraform, and represented a divergence from the treatment of `null` as equivalent to unset which exists in resources. The same behaviour exists in top-level variable definitions with `nullable = false`, and we consider this to be the preferred behaviour here too. This commit slightly changes default value application such that an explicit `null` attribute value is treated as equivalent to the attribute being missing. Default values for attributes will now replace explicit nulls.	4 years ago
James Bardin	893a5336d8	don't lose warnings from static validation ... Warnings were dropped from static reference validation if there weren't also errors in the configuration.	4 years ago
James Bardin	8354bc46cf	Merge pull request #31576 from hashicorp/jbardin/validate-deprecated-computed ... validate deprecated attributes from static traversals	4 years ago
James Bardin	1a5e403329	Merge pull request #31532 from hashicorp/jbardin/static-validate-nested-types ... Account for `NestedType` in static traversal validation	4 years ago
kmoe	621af43c04	fix missing output for applyable refresh plans (#31469)	4 years ago
James Bardin	25f5a81048	validate deprecated attrs from static traversals ... We can't validate that data from deprecated nested attributes is used in the configuration, but we can at least catch the simple case where a deprecated attribute is referenced directly.	4 years ago
zimbatm	7a9ccc03b2	command/fmt: support formatting multiple files ... All the code infrastructure was there to support formatting multiple files already. This makes `terraform fmt` more flexible and also compliant with the [treefmt formatter spec](https://numtide.github.io/treefmt/docs/formatters-spec.html)	4 years ago
Radek Simko	fc62afb6dc	fix: validate implied provider names in submodules (#31573)	4 years ago