terraform test: refactor manifest file for simplicity #37412
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to address the second of Sarah's concerns from the source branch. Namely, that the state files and manifest file are still be written even if they are empty / didn't error.
I did find the existing implementation of the manifest file to be confusing. States were being loaded and written at seemingly random times, and there was overlap between when things were being written into backends and into local files. There are two driving changes in this PR that I think simplify things a little bit:
This change did end up being larger than I expected, as I needed to move things around in quite a large number of places in order to get the kind of access needed to make the state loading work as intended. For that, I'm sorry. But, hopefully most of the smaller changes are just simple refactorings that you can understand.
There is also one behaviour change. When a run block with a backend fails to get destroyed, an entry is written into the manifest for that state file but it is no longer directly persisted to disk. Instead, the state as it exists with the failed destroy is written directly into the actual state backend. So, we have an entry in the manifest locally telling us the execution failed, but we don't keep duplicate copies of the state file around. Instead, during cleanup, the errored state is just loaded from the backend like normal instead of trying to sideload it locally. It seemed redundant and dangerous to hold competing copies of a state file in two locations.