Automate terragrunt configuration folder/file creation?

[JBallin]

Let's say I want to create a new terragrunt project with the following file structure:

├── accounts
│   ├── account-a
│   │   ├── modules
│   │   │   ├── module-a
│   │   │   │   └── terragrunt.hcl
│   │   │   ├── module-b
│   │   │   │   └── terragrunt.hcl
│   │   │   └── module-c
│   │   │       └── terragrunt.hcl
│   │   └── terragrunt.hcl
│   ├── account-b
│   │   ├── modules
│   │   │   ├── module-a
│   │   │   │   └── terragrunt.hcl
│   │   │   ├── module-b
│   │   │   │   └── terragrunt.hcl
│   │   │   └── module-c
│   │   │       └── terragrunt.hcl
│   │   └── terragrunt.hcl

Here's an example terragrunt.hcl:

include "root" {
  path = find_in_parent_folders()
}

include "model" {
  path = "${dirname(find_in_parent_folders())}/models/module-a/name.hcl"
}

Is there a way to automate creating these folders etc with some kind of config file that I would pass to a command like terragrunt config? Example config file:

module "accounts" {
  source  = "./accounts"

  module "modules" {
    source  = "./modules"
  }
}

And then within ./accounts and ./modules I would somehow define the account names and module names etc.

Why is this useful?

• DRY
• This would allow me to have a single config file instead of dealing with a bunch of nested folders - allowing me to easily add a new module to every account etc.
• I imagine I could even gitignore everything that would be generated by the config and instead only generate the folders when running terraform commands.
• It would allow other teams to easily adopt the project and customize it to their needs, instead of needing to deal with nested folders.
• It's easier to parse what's happening IMO.

---

Tracked in ticket #109757

[JBallin]

Realizing that root of this question is just about keeping terragrunt dry...which is already being discussed in multiple GitHub issues (e.g. gruntwork-io/terragrunt#759).

The only thing potentially novel in my post is the idea of a builder that automatically create configurations, but it may make more sense to continue working toward the existing RFC's for now.