Conditionally set attribute within a content block for modules

[benscholler-ciq]

Hi Terramate community and team! I'm running into an issue with module sources when using source and version attributes with a module block. Is it possible to conditionally set attributes within a module in a content block? I'm thinking it would be nice to have some sort of dynamic creation of individual attributes.

As a background, I'd like to keep the source and version for my registry module in sync everywhere between my stacks. In Terramate, I might do this to get close:

generate_hcl "_tm_gen_my_module.tf" {
  content {
    module "my_registry_module" {
      source  = tm_try(global.my_registry_module.source, "app.terraform.io/company/custom/module") # Supporting a default by using tm_try
      version = tm_try(global.my_registry_module.version, "0.0.1")
    }
  }
}

Let's say I'm testing something and want to reference a custom branch and deploy it to a development environment. When doing this, I could have a custom branch I need to reference. When using a reference to a custom branch in github, Terraform gets annoyed when specifying the version attribute, as it doesn't match version constraint standards. An empty string or null won't work for Terraform in this case:

globals "my_registry_module" {
  source = "[email protected]:company/terraform-custom-module.git?ref=my-testing-branch" # My custom branch to deploy for testing.
  version = null # How do I make it so this variable isn't set during code generation?
}

If setting null on the version in this case, Terraform will yell at you:

│ Error: Invalid registry module source address
│ 
│   on _tm_gen_my_module.tf line 10, in module "my_registry_module":
│   21:   source = "[email protected]:company/terraform-custom-module.git?ref=my-testing-branch"
│ 
│ Failed to parse module registry address: a module registry source address must have either three or four slash-separated components.
│ 
│ Terraform assumed that you intended a module registry source address because you also set the argument "version", which applies only to registry modules.

It would be nice to have dynamic/conditional attribute creation in this case. Something like:

generate_hcl "_tm_gen_my_module.tf" {
  content {
    module "my_registry_module" {
      source  = tm_try(global.my_registry_module.source, "app.terraform.io/company/custom/module")

      tm_dynamic_attribute "version" {
         condition = tm_try(global.my_registry_module.version, false)
         value = tm_try(global.my_registry_module.version, "0.0.1")
      }
    }
  }
}

To get around this, I could do some pre-pass funcationality to unset an attribute from a map for module attributes, but that seems overly complicated. Maybe there's another way I'm missing to handle this sort of behavior? Thanks for any help!

[i4ki]

Hi @benscholler-ciq

Sorry for the late reply... For some reason our team didn't receive any Github notifications for questions here in the past few months..

Terramate do support this use case with the tm_dynamic block. Example below:

generate_hcl "_tm_gen_my_module.tf" {
  lets {
    module_attrs = {
      source  = tm_try(global.my_registry_module.source, "app.terraform.io/company/custom/module")
      version = tm_try(global.my_registry_module.version, "0.0.1")
    }
  }
  content {
    tm_dynamic "module" {
      labels = ["my_registry_module"]
      attributes = {for k, v in let.module_attrs : k => v if v != null}
    }
  }
}

The {for ... k => v if v != null} will filter out the null cases and then those attributes will not be present in the generated code.

Does this work for you?

[benscholler-ciq]

Hi @benscholler-ciq

Sorry for the late reply... For some reason our team didn't receive any Github notifications for questions here in the past few months..

Terramate do support this use case with the tm_dynamic block. Example below:

generate_hcl "_tm_gen_my_module.tf" {
  lets {
    module_attrs = {
      source  = tm_try(global.my_registry_module.source, "app.terraform.io/company/custom/module")
      version = tm_try(global.my_registry_module.version, "0.0.1")
    }
  }
  content {
    tm_dynamic "module" {
      labels = ["my_registry_module"]
      attributes = {for k, v in let.module_attrs : k => v if v != null}
    }
  }
}

The {for ... k => v if v != null} will filter out the null cases and then those attributes will not be present in the generated code.

Does this work for you?

While this could work technically, it seems like a workaround and possibly a trap. There could be other attributes for a module that aren't defined when initially creating the module that should be defined, which could lead to a lot of back and forth to verify all the variables are set. Also, there could be other modules that depend on if this variable is set. Does this pattern become the standard way of creating a module in Terramate then?

This hasn't been a total blocker for us. We're relying on using the source attribute only with a ?ref= tag for our versioning. It would read a bit cleaner if we could use the source and version attributes.