Allow version to be variable in (sub)modules

[wjvanroosmalen]

I would like to have default sub module version and a variable input for submodules.

A solution could look like this:

module "solution" {
  source  = "app.terraform.io/customer/solution"
  version = "1.1.5"
  global_settings = var.global_settings
  account_id = var.global_settings.account_id

  networking_module_version = var.networking_module_version
  application_module_version = var.application_module_version
}

variable "networking_module_version" {
 default = "1.0.0"
}

variable "application_module_version" {
 default = "1.0.0"
}

Currently I need to update my solution module's submodule dependencies when they update. However, I would like to:

1. constrain my team that deploy solution to use certain defaults but,
2. allow differences between deployments that rely on changes in submodules.

Not sure if this is currently possible. It looks like it is not.

Current Terraform Version

0.15.2

Use-cases

Attempted Solutions

Proposal

References

[Ledermayer]

Upvote! Currently tf throws "Variables not allowed: Variables may not be used here.", when you try to feed version from a var or local. It would be nice to allow this, so we can bind a certain version as variable default, but leave the freedom for consumers to use older or preview/beta versions.

[zparnold]

+1

[thiagolsfortunato]

+1

[crw]

Thanks for your interest in this issue! This is just a reminder to please avoid "+1" comments, and to use the upvote mechanism (click or add the 👍 emoji to the original post) to indicate your support for this issue. Thanks again for the feedback!

[cgetzen]

I am trying to solve a slightly different problem: promoting module versions across environments without requiring a module to wrap the entire stack definition.

There are a variety of pre-processors that can be used as workaround: Terrafile, Terraspace custom helpers, and Terramate generation.

[dimisjim]

without requiring a module to wrap the entire stack definition.

Hey @cgetzen , interesting pointers to aforementioned solutions, but what do you mean by this?

[ncapps]

+1

[dgillman]

@ncapps please upvote the original comment ;-) +1 in a comment is not counted

[cveld]

I would already be pleased with a static local. E.g.

module "ref1" {
  source  = "somemodulereference"
  version = local.moduleversion
  ...
}

terraform
module "ref2" {
  source  = "somemodulereference"
  version = local.moduleversion
  ...
}

terraform
module "ref3" {
  source  = "somemodulereference"
  version = local.moduleversion
  ...
}

locals {
    moduleversion = "5.6.3"
}

I believe static locals would resolve fine during the init phase.

In Terraform cli's current version 1.3.3 this throws errors:

The Terraform configuration must be valid before initialization so that
Terraform can determine which modules and providers need to be installed.
╷
│ Error: Variables not allowed
│
│ On main.tf line 3: Variables may not be used here.
╵

╷
│ Error: Unsuitable value type
│
│ On main.tf line 3: Unsuitable value: value must be known
╵

[lquanx]

It's already 2 years now. I guess they will never work on this issue.

[maha51ece-tech]

Any Update on this issue .

[GISTech01]

Is there any update on the following?

[Schillman]

Would love to see this feature. Now I understand why people are creating two different code bases for dev and prod and why Google has it as their Best Practice, Do we have any updates on this?

[shreychen]

Any update on this issue. Look forward to this feature, too.

[draeath]

Is there a way to do this already, that's just not as clear?

It's getting to the point where I'm about to build my terraform files from jinja2 templates instead writing them directly.

[thiagolsfortunato]

any news? 👀

[Satak]

We have the same issue. This is a major blocker for us. I need to allow passing variables to module calls for version. Same issue as here: https://github.com/hashicorp/terraform-provider-tfe/issues/849

module "example" {
  source               = "app.terraform.io/XXXX/eks-cluster/aws"
  version              = var.module_version # <-- support this please
}

[alexanderogorodnikov]

+1

[ahoehma]

This would help a lot! I for example have multiple times to use the same module with version xxx and I have to maintain all these places. Please provide this feature.

[dcherniv]

Would love to see this feature. Now I understand why people are creating two different code bases for dev and prod and why Google has it as their Best Practice, Do we have any updates on this?

Frankly, Google's branches per environment is a terrible practice.

[Schillman]

Would love to see this feature. Now I understand why people are creating two different code bases for dev and prod and why Google has it as their Best Practice, Do we have any updates on this?

Frankly, Google's branches per environment is a terrible practice.

Wasn't referring to that, was referring to their not so DRY friendly way of working. Where they have several codebases for each environment. Never heard of Googles way of working when it comes to dedicated branches per environment. Do you have any source on that?