30379 Commits (ba113ff2cd3708d8a0e49df66d649774af5aaa4e)

 

All Branches   

Search

Author	SHA1	Message	Date
kmoe	ba113ff2cd	add destroy option to terraform apply help text (#31714)	4 years ago
kmoe	6ac24d8002	Update CHANGELOG.md	4 years ago
kmoe	a9155e9cfe	Update CHANGELOG.md	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
kmoe	3dbf5cc623	Update CHANGELOG.md	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	477f7fe9a9	Update CHANGELOG.md	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
Alisdair McDiarmid	1347aa29fd	Update init.mdx	4 years ago
Alisdair McDiarmid	0d35244253	Merge pull request #31682 from kmchau428/patch-1 ... Update init.mdx	4 years ago
Alisdair McDiarmid	e80f29df94	Update CHANGELOG.md	4 years ago
kmchau	38b3bf8edb	Update init.mdx ... rephrased according to the suggestion.	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
Martin Atkins	746bd49723	build: Exclude .pb.go files from goimports checking ... protoc-gen-go generates non-style-compliant import directives, but since those files are just generated anyway we don't need to worry too much about what style they are in: the style that protoc-gen-go generates is the canonical style for these ones.	4 years ago
Martin Atkins	443d470a86	build: FIXME to make goimportscheck.sh work on Bash 3 maybe	4 years ago
Martin Atkins	d735de3656	build: checks.yml GitHub Actions workflow doesn't need goimports installed ... The importscheck script now uses "go run" to run this program and so the Go toolchain will install it automatically using the version number of golang.org/x/tools specified in our go.mod file.	4 years ago
Martin Atkins	4c7f20853f	build: Run scripts directly from makefile, rather than via sh ... All four of these scripts have #! lines calling for them to run in bash, and they are all marked as executable, so there's no harm in running them directly and it makes it clearer that we're running them in the shell specified on the #! line, rather than with whatever "sh' happens to be on the current system. (Note that this _was_ still correctly using the #! lines before, because it's `sh -c` rather than just `sh`, but nonetheless that old way seemed needlessly confusing.)	4 years ago
Martin Atkins	edb1152ae0	build: Enable command echo for various Makefile targets ... When we run many of these together e.g. in the checks.yaml GitHub Actions workflow, it's hard to tell from the output exactly which command is producing which subset of the output. To help clarify that, we'll ask make to print out the command line it's running before it runs it.	4 years ago
Martin Atkins	c2ec25e359	build: goimports check relative to PR base branch ... At the risk of a little bit of hidden spooky action at a distance, this will slightly change the behavior of the "goimports check" to compare against the base branch of a PR rather than to origin/main if we happen to find one of the environment variables that GitHub Actions sets automatically in its runners. This is targeting our "checks.yml" workflow in particular. The intention here is to avoid misreporting files that haven't actually changed when a PR is targeting a branch other than the main branch, such as directly targeting a historical release branch. We'll still run against origin/main when we're not running in GitHub Actions, since that's _typically_ the correct branch to use for new work, even if it will eventually get backported to a release branch.	4 years ago
Martin Atkins	246686813d	build: goimports check supports any number of changed files ... The previous implementation of this check tried to accumulate all of the changed files into a single big string and then run goimports once with all of them, but that approach ran into problems for changesets of a certain (platform-specific) size due to limits on maximum command line length. This new version instead uses bash arrays and runs goimports separately for each of the files which appear to have changed relative to the base branch. This is likely to be slower to complete for changesets that have many different changed files, but it's better for it to be slow than to return an error and fail to check some of the files.	4 years ago
kmchau	031c8bba82	Update init.mdx	4 years ago
Megan Bang	4fab46749a	update persist state	4 years ago