spacelift.iois used here;
trueif your module manages Spacelift resources (and most likely it does not). Setting worker pool to the one you manage yourself makes sense if the module tests will be touching resources or accounts you don't want Spacelift to access directly. Plus, your private workers may have more bandwidth than the shared ones, so you may get feedback faster. The project root let's you specify the module source code root inside of your repository:
test_defaultsand each test case accepting the same configuration block. Note that settings explicitly specified in each test case will override those in the
test_defaultssection. Also, notice that each test case has a name, which is a required field.
TF_VAR_) through the test-level
environmentconfiguration option - see above for an example.
examples/directory of your repository showing users how they can use the module in practice. These examples can then become your test cases, and you can test them against multiple supported Terraform version to maximize compatibility.
negative, which means that it is expected to fail. In an example above one of the test cases is expected to fail if one of the required Terraform variables is not set. Negative test cases are as useful as positive ones because they can prove that the module will not work under certain - unexpected or erroneous - circumstances.
module_versionin the configuration. Important thing to note is that Spacelift will not let you reuse the number of a successful version, and will require you to strictly follow semantic versioning - ie. you can't go to from
.terraformrc). To learn more about this please refer directly to Terraform documentation.