You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

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
..
testdata/happypath	checks: A new package for modeling custom condition checks	4 years ago
doc.go	checks: A new package for modeling custom condition checks	4 years ago
state.go	states: Two-level representation of check results	4 years ago
state_init.go	core: Use the new checks package for condition tracking	4 years ago
state_report.go	core: Propagate check results accurately from plan to apply	4 years ago
state_test.go	states: Two-level representation of check results	4 years ago
status.go	checks: A new package for modeling custom condition checks	4 years ago
status_string.go	checks: A new package for modeling custom condition checks	4 years ago