terraform icon indicating copy to clipboard operation
terraform copied to clipboard

Add ability to parse backend blocks present in a test file's run blocks, validate configuration

Open SarahFrench opened this issue 10 months ago • 3 comments

Description

Note: This PR is targeted at a feature branch instead of main, as I'd like to avoid creating a single, large PR for this work. My intention is to do a few PRs into that branch and eventually make a PR for the whole feature branch into main. That's when the change file would be included.

This PR is the first step of adding support for backend blocks to run blocks in terraform test:

  • implement parsing of backend blocks from run blocks.
  • implement validation of backend blocks in the context of runs.

Luckily we can reuse the existing code for parsing backend blocks, so validation is the main problem being addressed in this PR.

Validation requirements

  • [x] Only state backends are supported
  • [x] Only one backend block per run block
  • [x] Only one backend block per internal state file (i.e. state_key value)
    • [x] Update run blocks to have their state key value set earlier if not explicitly set via config; needed to allow proper validation here
  • [x] For a given internal state file, the first command = apply run block must be where the backend block is used (if at all)
  • [x] Backend blocks must be unique within a given test file

SarahFrench avatar Feb 19 '25 20:02 SarahFrench

The crashes resulting from feb5a7b show that we're not setting the state key properly after the changes in 158151c.

I think that's because we don't set ConfigUnderTest until here: https://github.com/hashicorp/terraform/blob/3f4ed7e01921e7b9e8943875cf8bc97a3751395f/internal/configs/config_build.go#L34

and that code runs after we parse individual run blocks etc.

SarahFrench avatar Mar 04 '25 12:03 SarahFrench

The latest changes have:

  • Made sure that state keys for child modules are set during parsing of test files
  • Removed use of GetStateKey
  • Added some more tests that can adapt to runs being processed in different orders

SarahFrench avatar Mar 04 '25 17:03 SarahFrench

Sorry for the back and forth here! Previously I thought the different ordering that impacted the acceptance test were due to new behaviour in the test graph, but it was just due to iterating over a map 🤦🏻 . I've addressed that in 75dfe43

SarahFrench avatar Mar 05 '25 20:03 SarahFrench

Thanks both! 🙇🏻

SarahFrench avatar Mar 06 '25 10:03 SarahFrench

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

github-actions[bot] avatar Apr 06 '25 02:04 github-actions[bot]