Module Versions

Resourcely provides the ability to set constraints on the versions of Terraform modules in your configuration. There are two steps to achieve this:

1. Create a guardrail that applies a semantic version constraint on the version of a specific module.

2. Provide module version metadata to Resourcely during continuous integration.

Step 1: Guardrail

The following guardrail is an example that shows how to set up version constraints for a specific module, where the source is registry.terraform.io/carljavier/pet/random and the version must be at least 0.0.5.

GUARDRAIL "Require that pet/random uses version 0.0.5 or later"
  WHEN module.source = "registry.terraform.io/carljavier/pet/random"
    REQUIRE version MATCHES VERSION ">= 0.0.5"

Step 2: Module metadata

The module metadata that Resourcely uses to resolve the current versions of the modules in your configuration is the modules.json file created during terraform init. There are two ways to provide this required module metadata to support module version constraints:

1. Pass the --modules_file path directly to the Resourcely CLI, or

2. Pass the modules_file path as an attribute in the Resourcely Github Action.

Without this metadata, module version guardrails will not apply.

Testing

You can clone the scaffolding-version-module-update repository to test an integration with the Resourcely Github Action, where you will find detailed information about how to pass the module version metadata, and see what the results look like when a module version is not valid.