spacelift.io
is used here;config.yml
file in its .spacelift
directory, containing information about the module along with any test cases. Details of the format of this file can be found in the module configuration section of this page.true
if 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_defaults
and each test case accepting the same configuration block. Note that settings explicitly specified in each test case will override those in the test_defaults
section. Also, notice that each test case has a name, which is a required field.TF_VAR_
) through the test-level environment
configuration 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_version
in 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 0.2.0
to 0.4.0
, skipping 0.3.0
entirely..terraformrc
). To learn more about this please refer directly to Terraform documentation.